Hi Nathan et al,
> > [Are slabs a way to exploit partially damaged pages of RAM?]
> AFAIK, the slabs are continuous [...]
I wouldn't be surprised if that turns out to be an easy assumption for the
normal situation of 100% correct memory, that can be altered (without loss
of efficiency in the normal situation) to have a preference for bad RAM
pages on allocation, and achieve major improvements for bad RAM.
Slabs, by their nature, are not often deallocated and the additional
overhead for marking buffers in a slab `in use' because they cover bad RAM
seems fair to me.
> Yes, there is cause to allow the finer specification, but the code to parse
> & handle things that way appears to me excessive.
I tend to disagree. Attached you'll find my code for iterating over the
addresses matching an address/bitmask pair. It's small, general and beautiful.
[Then again, that may not be my most objective statement ever.]
I like the :X shorthand you mention. It is an easy way out for less
technical people. For the "tough guys", I still believe that precision of
specification of bad addresses will pay off in some future, either due to
slabs or due to any other optimisation. My bit masks allow any level of
precision you like, and the masks annotate the degree of precision
alongside the address. I believe we will need that information in the long
run.
-Rick
------------ 8< ------------ 8< ------------ 8< ------------ 8< ------------
/* Given a pointed-at address and a mask, increment the page so that the
* mask hides the increment. Return 0 if no increment is possible.
*/
static int next_masked_address (ulong *addrp, ulong mask)
{
ulong inc=1;
ulong newval = *addrp;
while (inc & mask)
inc += inc;
while (inc != 0) {
newval += inc;
newval &= ~mask;
newval |= ((*addrp) & mask);
if (newval > *addrp) {
*addrp = newval;
return 1;
}
do {
inc += inc;
} while (inc & ~mask);
while (inc & mask)
inc += inc;
}
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:31 EST