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

Eric W. Biederman
2006-07-12T16:37:13Z

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