> Bill Hawes <whawes@star.net> writes:
>
> |> The attached patch provides for variable-sized fd arrays, automatically
> |> expanding from a small default (32 files) to the full 1024 when needed. This
> |> results in a significant savings of non-pageable kernel memory (about 35 pages
> |> just for the system tasks), and should significantly speed up process forking
> |> when fewer than 32 files are used.
>
> |> The patch adds an FDSize: entry to the /proc/pid/status output so you can
> |> monitor which tasks are using more files. (As discussed previously on the list
> |> here, the bash shell opens fd 255 and therefore requires a full fd array.)
>
> How about expanding the fd array in more steps, perhaps 32 -> 256 -> 1024?
> Or make the default 64 files, and Bash could be changed to use fd 63
> instead (it already allocates from 63 downward for process substitutions).
Or use a sparse indirect array with e.g 64 pointer buckets. This could even
be made to work nicely with the slab allocator.
#define BUCKETSIZE 64
files_struct
...
int max_fds;
fd_bucket *ptr[(max_fds + (BUCKETSIZE-1)) / BUCKETSIZE];
fd_bucket
struct file *fhs[BUCKETSIZE];
fd_bucket could be managed by a slab cache, similar to files_struct. Using
a slab constructor the initialisation of the indirect pointers could be
made very efficient too [See how the fd array was cleared in < 2.1.89].
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu