Messages in this thread | | | Date | Thu, 13 Jul 2006 12:15:06 -0400 | From | "Albert Cahalan" <> | Subject | Re: [PATCH] Use uname not sysctl to get the kernel revision |
| |
On 7/13/06, Eric W. Biederman <ebiederm@xmission.com> wrote: > "Albert Cahalan" <acahalan@gmail.com> writes: > > Andi Kleen writes: > >> On Thursday 13 July 2006 01:24, Theodore Tso wrote: > > > >>> P.S. I happen to be one those developers who think the binary > >>> interface is not so bad, and for compared to reading from /proc/sys, > >>> the sysctl syscall *is* faster. But at the same there, there really > >>> isn't anything where really does require that kind of speed, so that > >>> point is moot. But at the same time, what is the cost of leaving > >>> sys_sysctl in the kernel for an extra 6-12 months, or even longer, > >>> starting from now? > >> > >> The numerical namespace for sysctl is unsalvagable imho. e.g. > >> distributions regularly break it because there is no central > >> repository of numbers so it's not very usable anyways in practice. > > > > Huh? How exactly is this different from system call numbers, > > ioctl numbers, fcntl numbers, ptrace command numbers, and every > > other part of the Linux ABI? > > The only practical difference is that what people use is > /proc/sys so the binary sysctl interface is not seriously maintained > and bugs crop up.
There is a chicken-and-egg problem here then. Let's fix it.
I maintain the sysctl program, which most Linux distributions run at boot. I agree to switch to the binary sysctl interface if somebody will maintain the kernel side of things. This will shave a bit of time off boot on nearly every Linux box out there. The total time saved is probably a human lifetime, so it's like saving somebody's life.
> > Normal sysctl works very well for FreeBSD. I'm jealous. > > They also have a few related calls that are very nice. > > > > Here we fight over a few CPU cycles in the syscall entry path, > > then piss away performance by requiring open-read-close and > > marshalling everything through decimal ASCII text. WTF? Let's > > just have one system call (make_XML_SOAP_request) and be done. > > There is a cost to open-read-close. But as a simple benchmark > against a file will show reading data from /proc/sys is much slower > than reading data from a file. > > From what I have been able to measure so far, open-read-close only > seems to double the cost over sysctl, and access can do the filename > resolution about as quickly as sysctl can deal with a binary path. So > I suspect it is the allocation of struct file that makes > open-read-close more expensive. Reading the data is in the noise.
Eh? A factor of two is not "in the noise".
> sysfs current does a lot better than /proc/sys I think it was only > 60% heavier than performing the same operation on a real file.
That is still a horrible way to piss away performance.
> Performance wise there does seem to be a problem with the > implementation. How to fix it I don't yet know. But I have > yet to see ascii text be implicated.
I have more experience with /proc. There, ASCII is known to be a problem.
Parsing a 64-bit number is horribly slow on i386.
Matching keywords, as is needed for /proc/*/status, is also horribly slow. I ended up using gperf to make a perfect hash table, then gcc's computed goto for jumping to the code, and it still wasn't cheap to do. (while /sys lacks this, the extra open-read-close is certain to be far worse) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |