[MUD-Dev] Re: TECH: prefetching/madvise (was: Distributed Muds)
bruce at puremagic.com
Fri Apr 27 00:41:10 New Zealand Standard Time 2001
Chris Gray wrote:
>> From: Ola Fosheim =?iso-8859-1?Q?Gr=F8stad?= <olag at ifi.uio.no>
>> Anyone know how to force a page to memory without accessing it?
>> (Like what you would do in order to avoid CPU cache misses) Could
>> be handy when you know that you are going to a certain set of
>> pages, real soon...
> Most Unices have an "madvise" call. Checking just now, I see that
> Linux has the call in a header file, but no man page for it. Might
> not do anything.
> If it works, it tells the OS that you plan on using certain regions
> of memory soon.
Linux gained support for madvise() and mincore() in 2.3.99preX
releases. glibc gained support contemporaneously. Solaris supports
it. FreeBSD 3.2 supports it as well (that's the earliest version that
I have access to).
I can't think of any time that I've seen these used in free software
though. Apart from the allocator and GC in TOM (from the perspective
of telling the OS that we -won't- need the memory soon rather than the
reverse), I'm not sure where I'd use them at this point either.
I'd at this point be more interested in figuring out good ways to do
pre-fetches of objects based on predictions that we'd need them soon
as a means for reducing iowait. This would tie in well with some
plans that I've got for moving to asynch I/O for the binary DB
routines. (But maintaining the ability to synchronize with the I/O
completion where it might be needed.) But, I've not really seen any
good heuristics for doing these types of pre-fetches. This gets back
to having a good set of diagnostic tools to watch what's happening at
the DB layer and to determining which tasks are executing which blocks
of code and accessing which objects. I'm hoping to add this to Cold
soon .. just a simple matter of time, and finding the enthusiasm for
rewriting part of the interpreter to be clean enough to enable this.
But even then, I suspect that the improvements that will be made will
be within the DB and the softcode, rather than trying to make the
driver more complicated and intelligent.
MUD-Dev mailing list
MUD-Dev at kanga.nu
More information about the MUD-Dev