Re: [PATCH] sysctl: Allow /proc/sys without sys_sysctl

[ebiederm@xmission.com (Eric W. Biederman)]

Andi Kleen <ak@suse.de> writes:

> On Wednesday 12 July 2006 17:32, Eric W. Biederman wrote:
>> Andi Kleen <ak@suse.de> writes:
>> 
>> >> So it will correctly handle that sysctl being compiled out, and
>> >> the fallback to using /proc.  The code seems to have been
>> >> doing that since it was added to glibc in 2000.
>> >
>> > Using /proc is extremly slow for this.
>> 
>> How so it is the same code in the kernel.  Is open much slower than
>> sys_sysctl?
>
> Yes, the VFS adds quite a lot of overhead with its zillions of
> locks and other complicated things.
>
> I have also people complaining about /proc/cpuinfo overhead.

Yes. I just confirmed that /proc/sys access is about an order
of magnitude slower.  I goofed and forgot to add you to the
cc list but I just sent a patch to Ulrich to switch glibc to using
uname for this case.  uname is even faster than sysctl.

I am very curious to understand where the overhead is coming
from.  It may just be the VFS or it may be stupidities in
the /proc implementation.  If things are really as bad as
they appear it puts a serious damper on the plan9 style everything
is a filesystem approach.

>> > You added significant cost to each program startup.
>> 
>> Not each program only the ones that use pthreads.
>
> In modern glibc it's basically everything

It shouldn't be.   You can support be thread safe without pulling
in glibc.  But yes it is common.

>> > I still think it's a good idea to simulate that sysctl and printk
>> > the others.
>> 
>> To reduce the noise something like that makes sense.  I'm going to
>> see if I can get glibc to use uname which should have the same effect.
>
> And still printk for all old binaries?  Not a good idea.
>
> You have to check for  this case in the printk stub anyways and 
> if you check for it you can as well emulate it
> (with a big fat comment that this won't be done for any other sysctl)

I will see how it goes.

Eric