Manfred,
Calling this a BUG is misleading. It is ok to be occasionally wrong
regarding the preemption priority as long as RT tasks are not involved.
This is due to the fact that PROC_CHANGE_PENALTIES are used, which already
provide for some priority inversion.
Hubertus Franke
email: [EMAIL
t/scheduling patches. The MQ kernel
scheduler sure can handle this
kind of load :-)
Hubertus Franke
Enterprise Linux Group (Mgr), Linux Technology Center (Member Scalability)
, OS-PIC (Chair)
email: [EMAIL PROTECTED]
(w) 914-945-2003(fax) 914-945-4425 TL: 862-2003
bert hubert <[
.
Hubertus Franke
Enterprise Linux Group (Mgr), Linux Technology Center (Member Scalability)
, OS-PIC (Chair)
email: [EMAIL PROTECTED]
(w) 914-945-2003(fax) 914-945-4425 TL: 862-2003
"Adam J. Richter" <[EMAIL PROTECTED]>@vger.kernel.org on 05/01/2001
12:18:10 AM
Sent by:
gt;counter <= 0) {
current->counter = 0;
current->need_resched = 1;
}
Hubertus Franke
Enterprise Linux Group (Mgr), Linux Technology Center (Member Scalability)
, OS-PIC (Chair)
email: [EMAIL PROTECTED]
(w) 914-945-2003(fax) 914-945-4425 TL: 862-2003
"
+ 1) >> 1;
- current->counter >>= 1;
- if (!current->counter)
- current->need_resched = 1;
+ p->counter = current->counter;
+ current->counter = 0;
+ current->need_resched = 1;
Hubertus Franke
Enterprise Linux Group (Mgr),
ed_data[cpu].schedule_data.curr != idle_task(cpu))
nr_pending--;
+}
#else
// on UP this process is on the runqueue as well
nr_pending--;
Hubertus Franke
Enterprise Linux Group (Mgr), Linux Technology Center (Member Scalability)
email: [EMAIL PROTECTED]
(w) 914-945-2003(f
lock contention surfaces, then this will shift in favor of MQ.
Hubertus Franke
Enterprise Linux Group (Mgr), Linux Technology Center (Member Scalability)
, OS-PIC (Chair)
email: [EMAIL PROTECTED]
(w) 914-945-2003(fax) 914-945-4425 TL: 862-2003
Torrey Hoffman <[EMAIL PROTECTED]>
ts
every scheduling cycle I'll write it.
Hubertus Franke
Enterprise Linux Group (Mgr), Linux Technology Center (Member Scalability)
, OS-PIC (Chair)
email: [EMAIL PROTECTED]
(w) 914-945-2003(fax) 914-945-4425 TL: 862-2003
"Timothy D. Witham" <[EMAIL PROTECTED]>@vger.kernel.
above and substantiate a bit the need
for 100s of running processes, without claiming that the
application is broke.
Hubertus Franke
Enterprise Linux Group (Mgr), Linux Technology Center (Member Scalability)
, OS-PIC (Chair)
email: [EMAIL PROTECTED]
(w) 914-945-2003(fax) 914-945-4425 TL
ss, one can see it can have some impact.
See for results for various combinations of poolsizes and balancings:
http://lse.sourceforge.net/scheduling/results012501/status.html#Load%20Balancing
Hubertus Franke
Enterprise Linux Group (Mgr), Linux Technology Center (Member Scalability)
email: [EMAI
in a more recent implementation. Also
combined that
with using a bitmask to represent non-empty tasks.
Hubertus Franke
Enterprise Linux Group (Mgr), Linux Technology Center (Member Scalability)
, OS-PIC (Chair)
email: [EMAIL PROTECTED]
(w) 914-945-2003(fax) 914-945-4425 TL: 862-2003
Davi
/scheduling/LB/loadbalance.c
a writeup explaining this concept is available under
http://lse.sourceforge.net/scheduling/LB/poolMQ.html
Prerequisite is the MQ scheduler...
http://lse.sourceforge.net/scheduling/2.4.1.mq1-sched
We need to update these for 2.4.3 (coming)
Hubertus Franke
Enterprise
0.4365.783 11.475
12 10.9256.787 11.646
16 11.4265.048 11.877
20 11.4383.895 11.633
24 11.4573.304 11.347
28 11.4953.073 11.09
32 11.53 2.944 10.898
Hubertus Franke
Enterprise Linux Grou
: http://lse.sourceforge.net/scheduling/2.4.1.mq1-sched
Pooling Extension:http://lse.sourceforge.net/scheduling/LB/2.4.1-MQpool
LoadBalancing:
http://lse.sourceforge.net/scheduling/LB/loadbalance.c
Hubertus Franke
Enterprise Linux Group (Mgr), Linux Technology Center (Member Scalability)
, OS-PIC
unning-tasks ~ #cpus then each task
should alot a reasonable amount of work and any small overhead incurred
should be amortizable. However as we contend if #running-tasks >> #cpus
is a situation we need to deal with, the living with the current lock
contention can really drag us down.
Hubert
scheduler simple.
If there are improvements and I don't believe the MQ is all that
complicated
and its well documented, why not put it in.
Hubertus Franke
Enterprise Linux Group (Mgr), Linux Technology Center (Member Scalability)
email: [EMAIL PROTECTED]
(w) 914-945-2003(fax) 914-945-44
most of the time other
then context switching + syscall under the scheduler lock. This we won't
see in real apps, that's why I think the chatroom numbers are probably
better indicators.
Hubertus Franke
Enterprise Linux Group (Mgr), Linux Technology Center (Member Scalability)
, OS-
23 : 3.332 1.850 2.231
24 : 3.403 1.901 2.272
25 : 3.472 1.865 2.251
26 : 3.540 1.923 2.305
27 : 3.604 1.872 2.295
28 : 3.680 1.900 2.333
29 : 4.204 1.883 2.329
30 : 4.256 1.944 2.358
31 : 3.875 1.936 2.325
32 : 4.476 1.953 2.339
Hubertus Franke
Enterprise Linux Group (Mgr), Linux Technology
MQ algorithm */
}
Just shooting from the hip here, lets restart this discussion.
Hubertus Franke
Enterprise Linux Group (Mgr), Linux Technology Center (Member Scalability)
, OS-PIC (Chair)
email: [EMAIL PROTECTED]
(w) 914-945-2003(fax) 914-945-4425 TL: 862-2003
Mike Kravetz <[EMAIL P
e.
We are automizing the reboot process right now where we are modifying the
lilol.conf so we can run many tests with different "maxcpus=.." unattended.
So little to do, so much time... ahhh make that so little time, so much to
do.
Hubertus Franke
Enterprise Linux Group (Mgr), Linux Techn
go to my top table hash, retrieve the first P entry with
!P->has_cpu and I am ready to go.
Hubertus Franke
Enterprise Linux Group (Mgr), Linux Technology Center (Member Scalability)
, OS-PIC (Chair)
email: [EMAIL PROTECTED]
(w) 914-945-2003(fax) 914-945-4425 TL: 862-2003
David Lang <
ncing
mechanism to redistribute work.
We have a simple prototype running demonstrating the idea.This could be
also useful for NUMA systems as well. We will post this patch over the MQ
soon on the site.
Hubertus Franke
Enterprise Linux Group (Mgr), Linux Technology Center (Member Scalability)
, OS
22 matches
Mail list logo
