Adapt and update AccessLabs' patches for reduced Tor memory consumption for embedded devices
These are a set of patches written by Access Labs. They claim that these patches reduce memory usage on small low memory devices.
The patches are in several different areas:
- using anonymous mmap() for storing large chunks of data (instead of tempfiles)
- persisting the keys into /etc/tor/keys, rather than putting them in /var (tmpfs on OpenWRT)
- using fixed values for should_rebuild_md_cache() && router_should_rebuild_store()
- reducing the age of microdesc (changing the compile time defines)
- using gzipped files for storing cache
I am including the files here as one ticket item rather than 5, but it might make sense to break them up into separate issues.
The source for these changes is the TorWRT package from Access Labs: https://accesslabs.org/wiki/TorWRT
Activity
changed milestone to %Tor: 0.3.4.x-final
Trac:
001-anon_mmap.patchTrac:
002-gzipped_cache.patch
Definitely worth looking into. (Are we sure the license on these is cool?)
Some of these look like they could never go into Tor per se -- for instance, the one about sticking keys in /etc -- if we wanted a separate key directory, it would need to be configurable, not a hardwired default.
The shorter desc lifetime patch seems like it should also be configurable.
Still gotta read the more complex ones.
Trac:
Status: new to needs_review
Milestone: N/A to Tor: 0.2.4.x-final
Keywords: embedded, low memory deleted, tor-client embedded low-memory addedThere is a trac at AccessLabs as well, but it looks like it hasn't been updated in a few months (after they closed "support 2.3.19"). Might be able to contact someone via there to get them to comment on these.
Having a specific key directory different from the TorDataDirectory is useful for an OpenWRT router (as I mentioned above) as it allows the keys to survive a reboot. Assuming that preserving the keys across reboots is actually a useful thing to do. I think it would be absolutely fine for the OpenWRT build process to pass in a couple of ./configure defines to make this happen, e.g. $ ./configure --enable-key-dir --with-key-dir=/etc/tor/keys
The use of mmap() rather than tempfile might be a total wash, as I'm not sure how tempfile() on a tmpfs differs from mmap(-1) in terms of memory usage. I would be surprised if they were hugely different. A small savings, sure, but I would really be shocked if it was a huge improvement.
The gzipped() file seems like it might be the biggest winner for mem usage. Compressing the data stored in the cache will really help with reducing memory consumption (I would imagine).
I can test the patches in a couple groups to see if they provide huge improvements. I will assume that the time to live patches aren't too important (they take hours to have any effect), so I'll ignore them. The anon_mmap() and the gzip cache are the most likely candidates for immediate improvement, with gzip the most likely to be useful. I will test memory consumption and CPU utilization with the following combinations:
- tor-alpha (vanilla build)
- tor-alpha + gzip
- tor-alpha + anon_mmap()
- tor-alpha + gzip + anon_mmap()
I'll report back the results of those changes. It is a bit hard to measure using only busybox, so the findings might be rough. Hopefully the memory savings are so profound that even busybox will detect them.
The device I am going to be testing on is a TP-LINK MR3040, which has the following spec: 400mhz MIPS cpu, 32mb RAM, 4mb Flash. This device can load tor-stable, but after doing so it is... unstable. This is due primarily to tor-stable requiring something like 20mb of RAM during load, and using 100% of CPU. I am hoping these patches will help significantly with that and bring the memory usage down to a sub-16mb size.
Ok, so I've done some testing and it turns out: a) testing memory consumption is harder than I thought, and b) the patches (in whichever combination) appear to have little to no effect. I think this is due to the length of testing being too short for the benefits of these patches to appear. I only tested them for less than an hour each.
Currently I have all the patches applied and running on my latest build. The memory consumption of Tor-alpha is around 11mb. With Tor-alpha vanilla (sans patches) the memory usage was the same, 11mb. Compared this with Tor, which used 16mb. I am happy keeping the patches on while I continue testing. I don't think they'll hurt performance and if they improve the memory consumption over extended use then that works for me.
Also, I have found the cause of Tor's 100% CPU utilization during load time. When OpenWRT boots up it doesn't have an accurate clock, so it starts at 00000000. Tor's init script launches at slot 50, and ntpd launches at 98. Tor complains about the serious clock skew and seems to be in a busy loop somewhere. Restarting the daemon after the time has been set correctly makes Tor start up properly w/o 100% CPU use.
Should I open a bug report?
-
Replying to cypherpunks:
Also, I have found the cause of Tor's 100% CPU utilization during load time. When OpenWRT boots up it doesn't have an accurate clock, so it starts at 00000000. Tor's init script launches at slot 50, and ntpd launches at 98. Tor complains about the serious clock skew and seems to be in a busy loop somewhere. Restarting the daemon after the time has been set correctly makes Tor start up properly w/o 100% CPU use.
Should I open a bug report?
Sounds like two bug reports are in order: one on OpenWRT about starting Tor before you know what time it is, and another about Tor wasting cycles when it starts with a very wrong clock. For the latter one, it would be really helpful to know where Tor is spending its time.