lkml.org 
[lkml]   [2002]   [Jan]   [12]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateSat, 12 Jan 2002 12:35:14 -0700
From yodaiken@fsmlabs ...
SubjectRe: [2.4.17/18pre] VM and swap - it's really unusable
On Sat, Jan 12, 2002 at 02:23:00PM -0500, Ed Sweetman wrote:
> hardware to hardware could have a higher priority than normal programs being
> run.   That way they're not preempted by simple programs, it would have to
> be purposely preempted by the user.

Priority is currently, and sensibly, by process. A process may run user
code, do sys-calls, or field interrupts both soft and hard. Now do you want to
adjust the priority at every transition?

> Lowering the latency, sure the low latency code probably does nearly as well
> as the preempt patch.  that's fine.  Shortening the time locks are held by
> better code can help to a certain extent (unless a lot of the kernel code is
> poorly written, which i doubt).  at it's present state though,  my idea to
> fix the kernel would be to give parts of the kernel where locks are made,

"Fix" what? What is the objective of your fix?


> that shouldn't be broken normally, higher priorities.  That way we can
> distinguish between safe locks to preempt at and the ones that can do harm.
> But those people who require their app to be treated special can run it
> with -20 and preempt everything.   To me that makes sense.  Is there a

So:
	get semaphore on slab memory and raise priority
		get preempted by "treated special" app that then
			does an operation on the slab queues 

Is that what you want?

> reason why it doesn't?  Besides ethstetics.   the only way the ethsetic

It doesn't work? Is that a sufficient reason?


-- 
---------------------------------------------------------
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:15    [from the cache]
©2003-2008