[RC5] LIFO? Is this true?

gindrup at okway.okstate.edu gindrup at okway.okstate.edu
Mon May 11 12:45:16 EDT 1998


     Solaris and Digital UNIX have implemented kernel preemption checking 
     before entering potentially long-running kernel operations, like 
     directory parse/lookup.  If a higher priority process than the 
     process that is requesting the kernel operation is available to run, 
     the kernel operation is interrupted to service the prior process.
     
     I recall that "the variable" to look at in this regard is kprunrun.
     
     This, of course, is important in avoiding priority inversion...  
     where the RC5 idle-time client prevents a hard real time interrupt 
     handler from running because the kernel is busy parsing a 1000 file 
     directory table...
     
     The OSes that implement more structed directories tend to suffer 
     rampant priority inversion for lots of other reasons.  MacOS is a 
     pime example of this although I hear that the NeXT part of Rhapsody 
     alleviated this somewhat (but I've seen no evidence of this).  OS/2 
     and NT have exactly the same problems.  In fact NT has bigger 
     priority inversion problems in its interrupt handling (see 
     "Interrupt Behavior in Windows NT", _Dr. Dobb's Journal_, April 
     1998) but that's not entirely relevant here...
            -- Eric Gindrup ! gindrup at Okway.okstate.edu


______________________________ Reply Separator _________________________________
Subject: Re: [RC5] LIFO?  Is this true? 
Author:  <rc5 at llamas.net> at SMTP
Date:    5/9/98 8:08 PM


'Paul West' said previously:
| 
| Ryan Anderson wrote:
| 
| > Wouldn't it be smart to have a separate buff-out for each 
| > block? 
| 
| No!   I sure don't want 1000 separate files in any directory.
     
Agreed.  Most filesystems (including the widely used FAT filesystem) 
perform horribly when there's many files in a directory.
     
Many Unixes also bog down horribly, since most directory searches are 
linear, and these long linear searches occur in kernel space -- 
effectively halting the whole system while the kernel looks for a 
particular file to open.  (That's big part of why news servers which 
store each article as a separate file get so heavily bogged down, 
actually.  A news admin friend of mine showed me this first-hand.)
     
Some OS's use a more intelligent directory structure (eg. b-tree, or 
other log(n) type of structure) that scales a little better with the 
number of files, but that still doesn't make the each-block-gets- 
a-file approach a win.  It's potentially easier to program, but it's 
alot slower, no matter what.
     
Ironically, it's probably *not* easier to program portably either, 
unless you make a separate "table of contents" file which tracks the 
list of blocks--thus nullifying any benefit of storing one block per 
file.  Reading directory entries tends to be rather OS-specific 
(although POSIX has helped alot there).
     
Regards,
     
--Joe
     
-- 
  +------- Joseph Zbiciak ------+
  |- - - j-zbiciak1 at ti.com - - -|   without you, everything falls apart 
  | -Texas Instruments, Dallas- |   without you, it's not as much fun 
  |- - #include <disclaim.h> - -|   - NIN -      to pick up the pieces. 
  +-----------------------------+
--
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net 
rc5-digest subscribers replace rc5 with rc5-digest
     
     

--
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest



More information about the rc5 mailing list