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