Messages in this thread | | | From | (Rick van Rein) | Subject | Re: Where is memory handed out? | Date | Tue, 21 Mar 2000 01:08:54 +0100 (MET) |
| |
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/
| |