lkml.org 
[lkml]   [1998]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: SMP scalability: 8 -> 32 CPUs
Date
>>>>> "Rik" == Rik van Riel <H.H.vanRiel@phys.uu.nl> writes:
> - - longer time slices (for CPU-bound tasks only!)
> - - make it harder to switch CPUs (depending on how long a process
> has slept)

Reminds me of a paper in the last ASPLOS (can't remember the title) from
some Stanford guys (IIRC) about providing more control on resources.
Basically they hacked the Irix kernel to allow partitioning the machine among a
few entities (can't remember the name they used, let's call them FURBs).
Each process is associated with a FURB (either by having one FURB per user or
one FURB per group or by mere inheritance, ...). Each FURB has access to some
subset of the machine's resources (they dealt with CPU, CORE and disk-IO).
The scheduling (and swapping and disk queue management) they use tries to make
sure that each FURB has indeed access to its alloted resources and if some FURB
doesn't use all of its resources, others can take advantage.
I.e. it gives you a mix of cluster and SMP, as well as another kind of `limit'
mechanism (you could simulate the SCHED_IDLE for rc5 by making a FURB with
0 CPU resources (it can only use idle resources of other FURBs)).
The reason why I thought about it is that they use the FURBs to partition
the machine at the CPU level: each FURB receives a (non-integral) number of
processors so it also somewhat limits processes hopping around from CPU to CPU.
(of course it's no replacement for a proper SMP-aware scheduler, but it's just
the reaosn why the orinigal message reminided of it)


Stefan "wondering what is the actual point of his messge"

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:45    [from the cache]
©2003-2011 Jasper Spaans