[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CMUCL's kernel requirements (long&educational)



[I do not think mja is interested in this]

Yes what you suggest would work, and if you make sure all the pages
and only those pages that contain code have the EXECUTE bit on you will
be avoiding all unnecessary cache flushes.  I believe that in one of the
latest rounds of changes to the mips pmap module adding the EXECUTE bit
does cause a cache flush [it does in 3.0 anyways, so that's the eventual
semantics], so you would not have to do it yourself.

I do not know how much of a performance benefit that would be, I guess
it might be visible if a large portion of the core is not code [you
would be saving when re-paging in non exec pages].  I really do not
have any idea how it would effect newspace&zerofill stuff, consider
that a zerofill fault is "only" about 400 microsec anyways so you'd
have to have an estimate of how long it takes to lisp to burn a page
to estimate the saving.

Of course since vm_allocate() does what it does (e.g. EXECUTE bit on)
on 2.5 this all must be dressed differently depending on which version
of the kernel you are using.  The most complete solution therefore
entails you fully vm_protect()ing your memory the way you intend it
to be, without relying on the defaults provided by the implementation
of vm_allocate().

It is also possible to distinguish between 3.0 and 2.5 kernels
dynamically if you want to skip the extra vm_protect call on 3.0.

On a separate issue now.  With the external pager experiment I had in
mind setting the stage for more testing of VM management from lisp.
One idea I had was to let lisp know what its working set allowances
are, so that it can tune GC automatically for instance.
That is, instead of throwing away non-modified core pages it might
be wiser at times for lisp to free garbage pages and make the kernel
happy with that.  The only issue (for me ;-) is to let the lisp
know when it should reclaim "all memory you can", cuz the kernel needs
it.
On paper sounds like it might do good.  What do you guys think?

sandro-

Re: ds5000. I won't be in soon, could you send me more info ?
It is known that the DEC driver has trouble dealing with
old revision hitachi disks (and/or in conjunction with
HP 1Gb disks).  How is your 3max configed ?