change pts allocation behaviour in
Subsystems (2)
PATCH 1/1 change pts allocation behaviour in
Hello,
Here is a patch to change the way ptses are allocated. It applies against
2.6.6-rc3. Basically it tries to humour old glibc by always obtaining a pts in the range of 0-255 first. However, if that fails, then it will search the higher ranges. The net effect should be that old glibc users won't notice problems until they try and get more than 256 concurrent ptses (which would break under the first-fit scheme anyway), yet we reduce the average number of iterations required to find a new pts when a lot are in use. In the very worst case of only one pts available, this still performs no worse than the either the old or more recent allocation schemes.
Thanks,
Steve.
drivers/char/tty_io.c +12 -2
@@ -1362,14 +1362,24 @@#ifdef CONFIG_UNIX98_PTYS if (device ==MKDEV (TTYAUX_MAJOR ,2 )) {/* find a device that is not in use. */ -static int next_ptmx_dev =0 ; +static int next_ptmx_dev =MAX_PREFERRED_PTY ; retval =-1 ; driver = ptm_driver; +/* first, try for a pty < 256 for old glibc that doesn't support +* larger pts numbers */ +for (index =0 ; index <MAX_PREFERRED_PTY && driver->refcount < pty_limit; index++) { +if (!init_dev (driver, index, &tty)) + goto ptmx_found; + } +/* nothing below MAX_PREFERRED_PTY, try something higher */ while (driver->refcount < pty_limit) { index = next_ptmx_dev; next_ptmx_dev = (next_ptmx_dev+1 ) % driver->num; -if (!init_dev (driver, index, &tty)) +if (!next_ptmx_dev) + next_ptmx_dev =MAX_PREFERRED_PTY ; +if (!init_dev (driver, index, &tty)) { goto ptmx_found;/* ok! */ + } }return -EIO ;/* no free ptys */ ptmx_found:
include/linux/tty.h +1 -0
@@ -35,6 +35,7 @@#define NR_UNIX98_PTY_DEFAULT 4096/* Default maximum for Unix98 ptys */ #define NR_UNIX98_PTY_MAX (1 << MINORBITS)/* Absolute limit */ #define NR_LDISCS 16 +#define MAX_PREFERRED_PTY 256/* we prefer to allocate ptys beneath this number */ /* * These are set up by the setup-routine at boot-time:
Re: [PATCH] change pts allocation behaviour in tty_io.c, v2
Quoted 2 lines · Steve Young
Here is a patch to change the way ptses are allocated. It applies against
2.6.6-rc3. Basically it tries to humour old glibc by always obtaining a pts
I realized this won't properly cope when driver->num < MAX_PREFERRED_PTY.
Use this patch instead. I've tested it on my box.
Thanks,
Steve.
drivers/char/tty_io.c +17 -6
@@ -1362,14 +1362,25 @@#ifdef CONFIG_UNIX98_PTYS if (device ==MKDEV (TTYAUX_MAJOR ,2 )) {/* find a device that is not in use. */ -static int next_ptmx_dev =0 ; +static int next_ptmx_dev =MAX_PREFERRED_PTY ; retval =-1 ; driver = ptm_driver; -while (driver->refcount < pty_limit) { - index = next_ptmx_dev; - next_ptmx_dev = (next_ptmx_dev+1 ) % driver->num; -if (!init_dev (driver, index, &tty)) - goto ptmx_found;/* ok! */ +/* first, try and allocate a pty < 256 for old glibc */ +for (index =0 ; index <MAX_PREFERRED_PTY && driver->refcount < pty_limit && index < driver->num; index++) { +if (!init_dev (driver, index, &tty)) + goto ptmx_found; + } +/* nothing below MAX_PREFERRED_PTY, try something higher, unless +* we've already run out of options */ +if (index != driver->num) { +while (driver->refcount < pty_limit) { + index = next_ptmx_dev; + next_ptmx_dev = (next_ptmx_dev+1 ) % driver->num; +if (!next_ptmx_dev) + next_ptmx_dev =MAX_PREFERRED_PTY ; +if (!init_dev (driver, index, &tty)) + goto ptmx_found;/* ok! */ + } }return -EIO ;/* no free ptys */ ptmx_found:
include/linux/tty.h +1 -0
@@ -35,6 +35,7 @@#define NR_UNIX98_PTY_DEFAULT 4096/* Default maximum for Unix98 ptys */ #define NR_UNIX98_PTY_MAX (1 << MINORBITS)/* Absolute limit */ #define NR_LDISCS 16 +#define MAX_PREFERRED_PTY 256/* we prefer to allocate ptys beneath this number */ /* * These are set up by the setup-routine at boot-time:
Quoted 5 lines · Steve Young
Here is a patch to change the way ptses are allocated. It applies against
2.6.6-rc3. Basically it tries to humour old glibc by always obtaining a pts in the range of 0-255 first. However, if that fails, then it will search the higher ranges.
Wouldn't we be better off with plain old first-fit-from-zero?
Quoted 4 lines · Andrew Morton
Quoted 2 lines
in the range of 0-255 first. However, if that fails, then it will search the higher ranges.
Wouldn't we be better off with plain old first-fit-from-zero?
In the typical case where <256 pts devices are allocated, you're right that
there will be no benefit over the first-fit-from-zero implementation. However when there are a lot of pts devices in use, the algorithm used for searching the high ranges ought to generally find a new pts in fewer iterations than just linearly searching from 0 to the maximum pts number. For example, if a system allocates 5000 ptses in a row, when it goes to look for a new one with first-fit-from-zero, that's 5001 iterations to find an available pts. Using the patch though, it will only take 257 iterations. As time goes on and ptses get allocated and freed the situation becomes a bit murkier, but the patch should still cut down the number of iterations required to find a free pts.
Thanks,
Steve.
Quoted 7 lines · Steve Young
Quoted 4 lines · Andrew Morton
Quoted 2 lines
in the range of 0-255 first. However, if that fails, then it will search the higher ranges.
Wouldn't we be better off with plain old first-fit-from-zero?
Quoted 7 lines
In the typical case where <256 pts devices are allocated, you're right that
there will be no benefit over the first-fit-from-zero implementation. However when there are a lot of pts devices in use, the algorithm used for searching the high ranges ought to generally find a new pts in fewer iterations than just linearly searching from 0 to the maximum pts number. For example, if a system allocates 5000 ptses in a row, when it goes to look for a new one with first-fit-from-zero, that's 5001 iterations to find an available pts.
first-fit-from-zero does not imply linear search! The idr.c code provides a logarithmic-time search.