Messages in this thread | | | Subject | Re: variable fd array patch for 2.1.90 | From | Andi Kleen <> | Date | 30 Mar 1998 15:52:35 +0200 |
| |
Andreas Schwab <schwab@LS5.informatik.uni-dortmund.de> writes:
> 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
| |