On Fri, Jan 17, 2003 at 12:09:58PM -0800, Ian Romanick wrote:
> 
> > struct memory_block {
> >     u32     age_variable;
> >     u32     status;
> > };
> > 
> >     Where the age variable is device dependant, but I would imagine in most
> > cases is a monotonically increasing unsigned 32-bit number.  There needs to
> > be a device driver function to check if an age has happened on the hardware.
> 
> I don't think having an age variable in the shared area is necessary or 
> sufficient.  That's what my original can-swap bit was all about.  Each 
> item that is in a block would have its own age variable / fence.  When 
> all of the age variable / fence conditions were satisfied, the can-swap 
> bit would be set.

Also, using an age variable leads to lots of other really difficult issues,
like what happens when it wraps around.  A clock algorithm (as it was
called in my undergraduate courses, anyway) for paging out would probably
be better.

>  > The BLOCK_LOG2 stuff is
> > a way to pack the usage of this block of memory in just a few bits.  We pack
> > log2 - 1, where we only accept usages of 2 bytes or more.  Using 2 bytes
> > could be considered empty.  We can store upto block usage sizes of 64k in
> > this manner.  I think that we want 64kb to be our maximum size for a block.
> 
> That's probably finer granularity than we need.  We could probably get 
> away with "empty", "mostly empty", "half full", "mostly full", and 
> "full".  Admittedly, that only saves one bit, but it removes the 64KB limit.
> 
> One thing this is missing is some way to prioritize which blocks are to 
> be swapped out.  Right now the blocks are stored in a LRU linked list, 
> but I don't think that's necessarilly the best way (the explicit linked 
> list) to go.
><snip>
> A lot of this is also very Linux specific.  What can we do to make as 
> much of this as possible OS independent?  I don't think our BSD friends 
> will be very happy if we leave them in the cold. :)  Linux is most 
> people's first priority, but it's not the /only/ priority...

So having the kernel do it probably isn't the best way. :)

-- 
http://trikuare.cx


-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to