On 17 Dec 2013, at 12:00, cinap_len...@felloff.net wrote:
thats a surprising result. by dog pile lock you mean the runq spinlock no?
I guess it depends on the HW, but I don´t find that so surprising. You are
looping
sending messages to the coherency fabric, which gets congested as a
Latency is worse than using mwait because you are sleeping unconditionally.
Mwait does not prevent you from getting the interrupt to schedule.
By this I mean that mwait unblocks on interrupt. You could do something
like
(you do exponential backoff calling sleep or sleep/wakeup in the
for those without much mwait experience, mwait is a kernel-only primitive
(as per the instructions) that pauses the processor until a change has been
made in some range of memory. the size is determined by probing the h/w,
but think cacheline. so the discussion of locking is kernel specific as
The original discussion started about the runq spin lock, but I
think the scope of the problem is more general and the solution can be
applied in user and kernel space both. While in user space you would
do sleep(0) in the kernel you would sched() or if you are in the
scheduler you would
thats a surprising result. by dog pile lock you mean the runq spinlock no?
--
cinap
thats a surprising result. by dog pile lock you mean the runq spinlock no?
yes.
- erik
On Tue Dec 17 08:40:23 EST 2013, quans...@quanstro.net wrote:
thats a surprising result. by dog pile lock you mean the runq spinlock no?
yes.
my guess is it is made worse by the probes outside the lock.
- erik
the idlehands() on 9front is as follows:
/*
* put the processor in the halt state if we've no processes to run.
* an interrupt will get us going again.
*/
void
idlehands(void)
{
extern int nrdy;
if(conf.nmach == 1)
halt();
else if(m-cpuidcx Monitor)
I am running a dual core setup. CPU info is:
vendor GenuineIntel
procmodel 00020655 / 00010800
features fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
features pse36 clflush dts mmx fxsr sse sse2 ss
features pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 x2apic popcnt aes
hypervisor
/*
* put the processor in the halt state if we've no processes to run.
* an interrupt will get us going again.
*/
void
idlehands(void)
{
extern int nrdy;
if(conf.nmach == 1)
halt();
else if(m-cpuidcx Monitor)
mwait(nrdy);
On Dec 16, 2013, at 10:34, erik quanstrom quans...@labs.coraid.com wrote:
/*
* put the processor in the halt state if we've no processes to run.
* an interrupt will get us going again.
*/
void
idlehands(void)
{
extern int nrdy;
if(conf.nmach == 1)
it won't be too late—as causing failures. i've tried testing this and
generally found that reduced contention on the dog pile lock means
unconditionally halting gives a performance boost.
- erik
What are the changes you made to 9atom to facilitate this? Just replacing the
Greetings,
I am running 9plan on VMware Fusion successfully, however, the CPU is
pegged. I've seen this before with DOS. Basically the OS has its own idle
loop so VMware sees it as always using CPU. There is a patch to fix this
issue with a DOS guest. Any ideas with 9front?
Thanks.
Blake
I am running 9plan on VMware Fusion successfully, however, the CPU is
pegged. I've seen this before with DOS. Basically the OS has its own idle
loop so VMware sees it as always using CPU. There is a patch to fix this
issue with a DOS guest. Any ideas with 9front?
change idlehands in
welcome to the club. now do the same thing with linux. and try to
regale your experience in less than 4 blogposts :)
Good point. I can't.
On Sun, Dec 15, 2013 at 8:58 PM, andrey mirtchovski
mirtchov...@gmail.comwrote:
welcome to the club. now do the same thing with linux. and try to
regale your experience in less than 4 blogposts :)
16 matches
Mail list logo
