magenta wrote:
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.
I think we're running into some terminology problems here. In the existing memory manager, the age is a "when was it last used" variable. In the new proposals, the age is a fence. There are still wrap-around issues. :(

[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. :)
Putting some stuff in the kernel is fine as long as we don't rely on exotic, Linux-specific in-kernel interfaces. Putting too heavy of a reliance on the new Linux AGPGART or on specifics of the Linux VM are likely to get us in trouble.

It will also make it more difficult to port to other systems. This might be a good time to look at what some of our kernel issues are. I seem to remember a thread about porting the DRM to Solaris that ultimately led to despair. :(



-------------------------------------------------------
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