sysctl: Document that sys_sysctl will be removed.

Signed-off-by Eric W. Biederman <[email protected]>

---
 Documentation/feature-removal-schedule.txt |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

Documentation/feature-removal-schedule.txt +0 -0

index e978943..bef1bf0 100644
@@ -250,3 +250,14 @@ Why:	These drivers never compiled since 
 Who:	Jean Delvare <[email protected]>
 
 ---------------------------

aha, patch 1/2 and patch 2/2 would have helped that. :)

commit 073cd7b5515a7f5b74dbb4917c717e3c390013e7

Author: ak <ak>
Date:   Sat Jul 12 16:45:55 2003 +0000

[PATCH] Deprecate numerical sysctl

Deprecate the numerical sysctl name space. People can use /proc/sys instead.

The numeric name space was never well maintained and especially in distribution kernels is not very consistent (everybody has their own extensions, conflicting with others). It's also a great source of rejects when merging patches. The name-based /proc/sys is a much better interface for this, which people should use instead.

Discussion of this on l-k found no advocate for it, so it seems to not be very popular anyways.

This patch deprecates numerical name space accesses to make it possible to remove them in the future. The only exception is kernel.version, which is used by glibc (this one has to be maintained forever)

BKrev: 3f103b43JQH2fwSWpRLoTKziIiqH1w

The comment about kernel.version is odd. That information is available in uname so I can't imagine why sys_sysctl would be an interesting source.

#include <string.h>
#include <stdio.h>
#include <sys/utsname.h>
#include <errno.h>
#include <stdarg.h>
#include <stdlib.h>
#include <sys/sysctl.h>
#include <fcntl.h>
#include <unistd.h>

static void uname_test(void)

{
	struct utsname uts;
	uname(&uts);
}

static void proc_test(void)

{
	int fd;
	char buf[512];
	fd = open("/proc/sys/kernel/version", O_RDONLY);
	read(fd, buf, sizeof(buf));
	close(fd);
}

static void sysctl_test(void)

{
	static int sysctl_args[] = { CTL_KERN, KERN_VERSION };
	char buf[512];
	size_t reslen = sizeof(buf);

	sysctl(sysctl_args, sizeof(sysctl_args)/sizeof(sysctl_args[0]),
		buf, &reslen, NULL, 0);
}

int main(int argc, char *argv[])

{
	void (*test)(void) = NULL;
	int reps = -1;
	int i;

	for (i = 1; i < argc; i++) {
		if (strcmp(argv[i], "--sysctl") == 0)
			test = sysctl_test;
		else if (strcmp(argv[i], "--uname") == 0)
			test = uname_test;
		else if (strcmp(argv[i], "--proc") == 0)
			test = proc_test;
		else 
			reps = atol(argv[i]);
	}
	if ((reps == -1) || (test == NULL)) {
		fprintf(stderr, "usage: [--sysctl | --uname | --proc] <reps>\n");

		return 1;
	}

	for (i = 0; i < reps; i++) {
		test();
	}
	return 0;
}

But uname is noticeably faster than sysctl and uname is more portable across linux flavors. So updating the glibc pthread code to use uname looks like the right way to implement is_smp_system.

Quoted 3 lines · Eric W. Biederman

But uname is noticeably faster than sysctl and uname is more portable across linux flavors. So updating the glibc pthread code to use uname looks like the right way to implement is_smp_system.

This is (was?) not the universal through. We used uname at some point but then I did some profiling and sysctl turned out to be faster.

If the reverse is true now I can certainly look into changing this but the evidence and ideally has to be there. The simplicity of the uname code should mean that it's faster.

In a year or two I'll remove the test anyway. By then there will likely not be any UP kernels on reasonable machines anymore and I can drop all the conditional code.

Unless a darn good reason for keeping it is found, sys_sysctl won't be in the kernel several months from now. And uname is faster by a large margin than /proc.

Right now because there has been a deprecated note in "include/linux/sysctl.h" since 2003 people currently feel fine with letting sys_sysctl code bit rot. I am trying to resolve that situation most likely by just updating the few stray pieces of user space that care and then cutting out that chunk of kernel code.

Um, if glibc is using sys_sysctl, then that's a pretty good reason. Once we remove it from the kernel, then people will be forced to upgrade glibc's before they can install a newer kernel. Can we please give people some time for an version of glibc with this change to make it out to most deployed systems, first? It's really annoying when it's not possible to install a stock kernel.org kernel on a system, and often upgrading glibc is not a trivial thing to do on a distribution userspace, especially if there is a concern for ISV compatibility. (Especially if C++ code is involved, unfortunately.)

What we should do is what we've done in the past before removing a system call like this. printk a deprecation warning no more than n times an hours with the process name using the deprecated interface.

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?

glibc still works, just slower. But I think the best strategy is just to emulate the single sysctl glibc is using and printk for the rest.

Quoted 3 lines

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.

That may be true, but it doesn't answer the question, what's the cost of leaving in sys_sysctl in there for now?

Quoted 3 lines · Andi Kleen

glibc still works, just slower. But I think the best strategy is just to emulate the single sysctl glibc is using and printk for the rest.

That sounds reasonable, yes.

Quoted 4 lines

Quoted 3 lines

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?

Quoted 3 lines

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.

That may be true, but it doesn't answer the question, what's the cost of leaving in sys_sysctl in there for now?

In any case, if we really do want to get rid of it, the next step should be a working deprecation printk

and adding something to
Documentation/feature-removal-schedule.txt.

Quoted 3 lines

Unless a darn good reason for keeping it is found, sys_sysctl won't be in the kernel several months from now. And uname is faster by a large margin than /proc.

Um, if glibc is using sys_sysctl, then that's a pretty good reason. Once we remove it from the kernel, then people will be forced to upgrade glibc's before they can install a newer kernel. Can we please give people some time for an version of glibc with this change to make it out to most deployed systems, first? It's really annoying when it's not possible to install a stock kernel.org kernel on a system, and often upgrading glibc is not a trivial thing to do on a distribution userspace, especially if there is a concern for ISV compatibility. (Especially if C++ code is involved, unfortunately.)

We will need an implementation that will fall back to sys_sysctl for older kernels. This is already common practice in glibc. I don't really understand the performance concern because it seems to me that _is_smp_system() is only called once per process.

But isn't this the kind of thing that the Aux Vector is for? I like vDSO too, but I think it is best deployed for information of a more dynamic nature and performance sensitive.

Quoted 8 lines

We will need an implementation that will fall back to sys_sysctl for older kernels. This is already common practice in glibc. I don't really understand the performance concern because it seems to me that _is_smp_system() is only called once per process.

But isn't this the kind of thing that the Aux Vector is for? I like vDSO too, but I think it is best deployed for information of a more dynamic nature and performance sensitive.

For a simple "is_smp" kind of flag, I would tend to agree with the above... for more complex NUMA topology and/or cache characteristics, which is quite a bigger amount of information, I'm not sure it's worth copying all of that data on every process exec (and making the initial AT_ parsing slower). Especially since very few processes actually care about those.

Quoted 3 lines · Eric W. Biederman

Unless a darn good reason for keeping it is found, sys_sysctl won't be in the kernel several months from now. And uname is faster by a large margin than /proc.

Um, if glibc is using sys_sysctl, then that's a pretty good reason. Once we remove it from the kernel, then people will be forced to upgrade glibc's before they can install a newer kernel. Can we please give people some time for an version of glibc with this change to make it out to most deployed systems, first? It's really annoying when it's not possible to install a stock kernel.org kernel on a system, and often upgrading glibc is not a trivial thing to do on a distribution userspace, especially if there is a concern for ISV compatibility. (Especially if C++ code is involved, unfortunately.)

Quoted 5 lines

Right now because there has been a deprecated note in "include/linux/sysctl.h" since 2003 people currently feel fine with letting sys_sysctl code bit rot. I am trying to resolve that situation most likely by just updating the few stray pieces of user space that care and then cutting out that chunk of kernel code.

What we should do is what we've done in the past before removing a system call like this. printk a deprecation warning no more than n times an hours with the process name using the deprecated interface. A deprecated note in a header isn't necessarily something which will be noticed by userspace programmers. Heck, it isn't even in Documentation/feature-removal-schedule.txt yet.

If people want to remove it, let's please do this in an orderly fashion, and with ample warning that people besides kernel developers will actually *notice*.

- Ted

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?

Or if we going to remove parts of sysctl, can we at least keep enough there so that existing glibc systems don't break?

We could also put the uname info (modulo nodename) into the vDSO.

Quoted 1 line · Roland McGrath

We could also put the uname info (modulo nodename) into the vDSO.

Or even better: real topology information.

Quoted 3 lines · Ulrich Drepper

Quoted 1 line · Roland McGrath

We could also put the uname info (modulo nodename) into the vDSO.

Or even better: real topology information.

AND rather than OR would be even better. So glibc could find kernel version, etc. and topology in the vDSO cheaply.

Quoted 6 lines · Jakub Jelinek

Quoted 3 lines · Ulrich Drepper

Quoted 1 line · Roland McGrath

We could also put the uname info (modulo nodename) into the vDSO.

Or even better: real topology information.

AND rather than OR would be even better. So glibc could find kernel version, etc. and topology in the vDSO cheaply.

Wouldn't it make more sense for this to be in ELF tags, rather than the vdso? Another alternative, I guess, would be to put a pointer in the ELF tags, which may point into the vdso.

Quoted 11 lines · H. Peter Anvin

Quoted 6 lines · Jakub Jelinek

Quoted 3 lines · Ulrich Drepper

Quoted 1 line · Roland McGrath

We could also put the uname info (modulo nodename) into the vDSO.

Or even better: real topology information.

AND rather than OR would be even better. So glibc could find kernel version, etc. and topology in the vDSO cheaply.

Wouldn't it make more sense for this to be in ELF tags, rather than the vdso? Another alternative, I guess, would be to put a pointer in the ELF tags, which may point into the vdso.

Cheap and simple access to topology information would be interesting.

Glibc just wants to know if our kernel is SMP so it can know if it is ok to busy wait for a bit waiting for a mutex. Or if busy waiting is a complete loss.

Quoted 11 lines · Eric W. Biederman

Quoted 9 lines · H. Peter Anvin

Quoted 6 lines · Jakub Jelinek

Quoted 3 lines · Ulrich Drepper

Quoted 1 line · Roland McGrath

We could also put the uname info (modulo nodename) into the vDSO.

Or even better: real topology information.

AND rather than OR would be even better. So glibc could find kernel version, etc. and topology in the vDSO cheaply.

Wouldn't it make more sense for this to be in ELF tags, rather than the

vdso?

Quoted 1 line

Quoted 1 line

Another alternative, I guess, would be to put a pointer in the ELF tags,

which

Quoted 4 lines

Quoted 1 line

may point into the vdso.

Cheap and simple access to topology information would be interesting.

Quoted 3 lines

Glibc just wants to know if our kernel is SMP so it can know if it is ok to busy wait for a bit waiting for a mutex. Or if busy waiting is a complete loss.

with current power management... busy waiting pretty much is a loss even on UP

It is a short busy wait before falling asleep. I assume you mean busy wait is a loss even on SMP?

Quoted 2 lines

It is a short busy wait before falling asleep. I assume you mean busy wait is a loss even on SMP?

eh yeah I forgot to think for a second. But yes even for SMP busy wait is pretty bad power wise nowadays.. at least if you wait more than a few hundred cycles. (and if you wait less... then it's almost unlikely that it'll be useful as well)

Quoted 7 lines · Arjan van de Ven

Quoted 2 lines

It is a short busy wait before falling asleep. I assume you mean busy wait is a loss even on SMP?

eh yeah I forgot to think for a second. But yes even for SMP busy wait is pretty bad power wise nowadays.. at least if you wait more than a few hundred cycles. (and if you wait less... then it's almost unlikely that it'll be useful as well)

It depends greatly; if a lock is likely to get released by the user after a few memory accesses, spinning is likely to be a win.

Quoted 3 lines

Quoted 1 line

It depends greatly; if a lock is likely to get released by the user after a few memory accesses, spinning is likely to be a win.

But this requires that the lock be short lived, and highly contended.

If the lock is not short lived then the release is like to be a long ways off. If the lock is not highly contended then you are not likely to hit the window when someone else as the contended lock.

How frequent are highly contended short lived locks in user space?

If the lock is not short lived then the release is like to be a long ways off. If the lock is not highly contended then you are not likely to hit the window when someone else as the contended lock.

How frequent are highly contended short lived locks in user space?

[Disclaimer: There is a patent issue around this technique but its not one that will impact GPL code as permissions are given for GPL use.]

glibc is (and has to be) LGPL.

Anyway, it seems absolutely insane that having a programmable threshold for spinning is patented...

Ar Mer, 2006-07-12 am 16:26 -0600, ysgrifennodd Eric W. Biederman:

Quoted 4 lines

If the lock is not short lived then the release is like to be a long ways off. If the lock is not highly contended then you are not likely to hit the window when someone else as the contended lock.

Quoted 1 line

How frequent are highly contended short lived locks in user space?

I'm not sure it matters.

If you want to do the job right then do this

- Stick an indicator of how much else wants to run on this CPU in the vsyscall page or similar location

In your locks you can now do

              while(try_and_grab_lock() == FAILED) {
                       if (kernelpage->waiting > 0)
                              sys_somelockwaitthing()
              }

Furthermore the kernel can be intelligent about the waiting indicator for power or other global scheduling reasons

[Disclaimer: There is a patent issue around this technique but its not one that will impact GPL code as permissions are given for GPL use.]

Alan

Quoted 5 lines

If you want to do the job right then do this

- Stick an indicator of how much else wants to run on this CPU in the vsyscall page or similar location

Except that "this cpu" doesn't really mean anything in userspace, and while I think Andi has some tricks to get some sort of CPU number to userspace (though it's really only valid during the execution of the instruction that reads it :) I haven't yet found an equivalent for powerpc (and possibly other architectures will have the same problem).

Quoted 10 lines · H. Peter Anvin

Quoted 6 lines · Jakub Jelinek

Quoted 3 lines · Ulrich Drepper

Quoted 1 line · Roland McGrath

We could also put the uname info (modulo nodename) into the vDSO.

Or even better: real topology information.

AND rather than OR would be even better. So glibc could find kernel version, etc. and topology in the vDSO cheaply.

Wouldn't it make more sense for this to be in ELF tags, rather than the vdso? Another alternative, I guess, would be to put a pointer in the ELF tags, which may point into the vdso.

Cheap and simple access to topology information would be interesting.

Glibc just wants to know if our kernel is SMP so it can know if it is ok to busy wait for a bit waiting for a mutex. Or if busy waiting is a complete loss.

The practical challenge is that topology information is not fixed but potentially varies at runtime.

Ulrich what would be interesting besides the possibility of having multiple cpus?

Glibc just wants to know if our kernel is SMP so it can know if it is ok to busy wait for a bit waiting for a mutex. Or if busy waiting is a complete loss.

Ulrich what would be interesting besides the possibility of having multiple cpus?

I guess I should try to come up with a representation for this knowledge.

Quoted 2 lines · Eric W. Biederman

Ulrich what would be interesting besides the possibility of having multiple cpus?

What is needed for various things like memory handling etc is all topology information. Somebody might remember the numa library proposal I had in April 2004 which was cast aside because people were only looking for a "quick fix". Well, the problem still isn't solved.

IMO the vdso should export information about:

- processors and their relationship (hyperthreads, cores)

- the CPU caches and how they relate to the cores (e.g., dual core with shared L2)

- local main memory for each processor

- relative costs of the memory access of the various memory regions (for numa local memory to a node, intra-node costs)

- ideally, relative costs main memory and CPU caches

All this information can be steadily updated by the kernel as new CPUs/memory get added/removed. The vdso should have functions to access this information. It's easy enough to make this access race free.

I guess I should try to come up with a representation for this knowledge. Collecting the information (except the costs) should be easy. Determining the costs also shouldn't be that hard but it can be very useful. Some of this information could be determined at userlevel but you really don't want every process to compute all this from scratch. And stored data in a file is stale if the system changes.

Quoted 21 lines · Ulrich Drepper

Quoted 2 lines · Eric W. Biederman

Ulrich what would be interesting besides the possibility of having multiple cpus?

What is needed for various things like memory handling etc is all topology information. Somebody might remember the numa library proposal I had in April 2004 which was cast aside because people were only looking for a "quick fix". Well, the problem still isn't solved.

IMO the vdso should export information about:

- processors and their relationship (hyperthreads, cores)

- the CPU caches and how they relate to the cores (e.g., dual core with shared L2)

- local main memory for each processor

- relative costs of the memory access of the various memory regions (for numa local memory to a node, intra-node costs)

Quoted 7 lines

- ideally, relative costs main memory and CPU caches

All this information can be steadily updated by the kernel as new CPUs/memory get added/removed. The vdso should have functions to access this information. It's easy enough to make this access race free.