Tim Robbins <tjr_at_freebsd.org> writes: > It doesn't seem to make a noticeable impact on execution time for processes > with small numbers of descriptors. It's probably swamped by the overhead of > mode switches, locking, and filesystem operations. What makes uneasy is the > amount of extra memory it consumes when processes have a small number of > descriptors: (32**2)/8 = 128 bytes (when int is 32 bits), or (64**2)/8 = > 512 bytes (when int is 64 bits). I'm not sure where you get these numbers from. Actual growth of struct filedesc is: - two pointers - one 32-bit int (himap) (used when nfiles <= 1024) - one array of 32 32-bit ints (lomap) (used when nfiles <= 1024) For higher values of nfiles, larger arrays are malloc'ed and the static arrays are left unused. The total is 35*4 = 140 bytes per struct filedesc on 32-bit platforms and 2*8 + 33*4 = 148 bytes per struct filedesc on 64-bit platforms. Modifying the code to use 64-bit ints on 64-bit platforms would change that number to 67*8 = 536 bytes per struct filedesc, but the cutoff would be at nfiles == 4096 instead of 1024. > I've been thinking of switching to a flat > bitmap for small fd tables, possibly just using a single "int", or falling > back to the old way of scanning fd_ofiles directly. That would increase code complexity. The patch already increases fd allocation overhead by about 7% on my ev56 and 1% on my p4 for low values of nfiles (though the performance improvement for higher values is immense). It is possible that a pure 64-bit implementation would fare better on the Alpha than the current 32-bit implementation. > Once I decide what to > do about that and find someone to test my latest patch on a 64-bit machine, > I'll commit it. It works fine on my Alpha, using 32-bit ints. I haven't tried modifying the patch to use 64-bit ints on 64-bit platforms. DES -- Dag-Erling Smørgrav - des_at_des.noReceived on Thu Dec 04 2003 - 06:24:31 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:32 UTC