From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 30 Aug 1999 20:28:18 -0400 (EDT) From: Vladimir Dergachev Subject: Re: accel handling In-Reply-To: <14282.37533.98879.414300@dukat.scot.redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: "Stephen C. Tweedie" Cc: Marcus Sundberg , linux-mm@kvack.org, James Simmons List-ID: On Mon, 30 Aug 1999, Stephen C. Tweedie wrote: > Hi, > The only way to do it is to flip page tables while the accel engine is > running. You may want to restore it on demand by trapping the page > fault on the framebuffer and stalling until the accel lock is released. > This can be done, but it is really expensive: you are doing a whole pile > of messy VM operations every time you want to trigger the accel engine > (any idea how often you want to flip the protection, btw?) > > So you are talking several system calls, SMP inter-processor interrupts > and piles of VM page twiddling every time you want to claim and release > the core engine. Sorry, folks, but there's no way of avoiding the > conclusion that this is going to be expensive. In the single-CPU or > single-thread case the cost can be kept under control, but it is not > going to be cheap. > What about forbidding concurrency for the processes that have mmapped the framebuffer/accelerator ? Say assign all of them to one(or same) cpu permanently. If someone really wants it's process to run on more than one cpu (I don't think Linux does this currently) they had to do some extra work anyway. Vladimir Dergachev > --Stephen > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://humbolt.geo.uu.nl/Linux-MM/ > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://humbolt.geo.uu.nl/Linux-MM/