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