Re: Dynamic symbol table

Hi,

On Tue, 20 Jul 2004, Oswald Buddenhagen wrote:

> On Tue, Jul 20, 2004 at 10:08:02AM -0400, Maks Orlovich wrote:
> > > asynchronicity implies concurrency and concurrency implies trashing.

?  Reading page for page in user space has the exact same problem (because 
many processes try this).  It's even worse in user space because in 
kernel space it can merge requests and resort reads to reduce seeking.

> > Asynchronous I/O implies that the I/O scheduler can reorder requests
> > to reduce seeking. Which it can't do with synchronous requests.
> >
> sure, but this works only as long as the background loading is not
> interrupted by "forced reads".

What means "forced reads" ?  You mean a pageread for pagefaults?  I trust 
the kernel to reorder all request in some optimal sense.  If for this it 
has to first do this pagein before the madvise-queued blocks, it will do 
so.  If not then not.

> iow, as long as the kernel can't tell us that it is ready with the
> background loading, we're prolly better off doing it synchronously.

No.  When you try this you will notice very fast that user-spaced 
force-pagein is extremely slow.  And it slows down the process itself, 
because it sleeps until the page is there.  Unlike madvise, which just 
puts those request into the queue and returns.  I.e. the kernel will 
pagein many of the pages while the application is still doing all the 
KApplication ctor gunk.

And because there are more than one application starting up at the same 
time in a typical KDE start, this all will be even worse, because you give 
the kernel no chance to merge requests, and instead wait for each page to 
arrive.

> and quite honestly, i don't think the few somewhat bigger seeks
> resulting from reading the elf sections in suboptimal order come even
> remotely close to the impact of thousands of seeks resulting from
> concurrent demand loading.

?  You may think as much you want.  Experimenting is better though ;)

Like said above, doing madvice()-like thing from user-space is hopeless.  
So the question is only between madvise() or not madvise() at all (i.e.
demand paging by first page access).  The latter results in seeks and
pagefaults but uses potentially less memory.  If one or the other is
faster has to be tested.  We did, and madvise() was faster or on some
machines equally fast.


Ciao,
Michael.