Messages in this thread |  | | | Subject | Re: [PATCH 22/23] sysctl arm: Remove binary sysctl support | | From | (Eric W. Biederman) | | Date | Mon, 09 Nov 2009 03:45:06 -0800 |
Andi Kleen <andi@firstfloor.org> writes:
> ebiederm@xmission.com (Eric W. Biederman) writes: >> >> The glibc pthread code that uses sysctl has no problems if sys_sysctl >> is gone. It both falls back to reading /proc/sys and it just controls >> an optimization and the code works with either result. Been there, >> done that. > > /proc/sys is much slower than sysctl though. So you made program startup > slower.
Not much slower, but slower. I just measured it in a case that favors sysctl and the ration is about 5:2. Or sysctl is about 2.5x faster. About 49usec for open/read/close on proc and 19usec for sysctl. In my emulation it is a bit slower than that.
> Also I agree with Arjan that breaking such a common ABI is not > really a good idea. But I think it's enough to only handle > common sysctls that are actually used, which are very few.
Well I haven't broken anything at this point. I am simply edging us to the point when we are close to being able to forget about sys_sysctl for good.
As for the rest the common number of sysctls with glibc > 2.8 is exactly 0. Which makes compiling out sys_sysctl support sane. Especially since we have been throwing a warning for years if anyone uses any of the others. > It would be better to simply keep the commonly used binary sysctls > as emulation around always (commonly = used by glibc and perhaps > added by user printk feedback) That's very cheap because it's just > a simple translation and can be done internally cheaper than going > through the VFS with a bazillion of locks.
A micro optimization for code that does not exist. That is a bad trade off.
Further it is my intention to optimize /proc/sys when I get the chance now that we don't have all of the old sysctl baggage holding back the code.
I don't see anything that makes the date in Documentation/feature-removal-schedule.txt of September 2010 unrealistic.
Ultimately what drives me most is that people are still accidentally adding binary sysctls, which no one uses or tests. For a recent example see:
> commit 4663712cc745324a216112a72c744bb2b8f6658b > Author: Leo Chen <leochen@broadcom.com> > Date: Fri Aug 7 19:56:19 2009 +0100 > > ARM: 5643/1: bcmring: arch.c and header files > > add arch.c in mach-bcmring > add related header files in mach-bcmring > > Signed-off-by: Leo Chen <leochen@broadcom.com> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Andi if you want to do the do the legwork and optimize sysctl_binary.c so it does a better job, for that one sysctl older glibc's use, feel free to write the code.
I don't care enough, and I expect to upgrade to a glibc without the a single sysctl call before it would possibly matter to me.
Eric
|  |