From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Blaisorblade <blaisorblade@yahoo.it>
Cc: user-mode-linux-devel@lists.sourceforge.net,
Bodo Stroesser <bstroesser@fujitsu-siemens.com>,
akpm@osdl.org, jdike@addtoit.com, linux-kernel@vger.kernel.org
Subject: Re: [uml-devel] [patch 02/12] uml: cpu_relax fix
Date: Thu, 24 Mar 2005 13:09:41 +1100 [thread overview]
Message-ID: <42422165.20505@yahoo.com.au> (raw)
In-Reply-To: <200503240250.38153.blaisorblade@yahoo.it>
Blaisorblade wrote:
> On Wednesday 23 March 2005 18:09, Bodo Stroesser wrote:
>
>>blaisorblade@yahoo.it wrote:
>>
>>>Use rep_nop instead of barrier for cpu_relax, following $(SUBARCH)'s
>>>doing that (i.e. i386 and x86_64).
>>
>>IIRC, Jeff had the idea, to use sched_yield() for this (from a discussion
>>on #uml).
>
> Hmm, makes sense, but this is to benchmark well... I remember from early
> discussions on 2.6 scheduler that using sched_yield might decrease
> performance (IIRC starve the calling application).
>
Typically, for places where cpu_relax is used, sched_yield would be
a poor fit. So yes it could easily reduce performance.
> Also, that call should be put inside the idle loop, not for cpu_relax, which
> is very different, since it is used (for instance) in kernel/spinlock.c for
> spinlocks, and in such things. The "Pause" opcode is explicitly recommended
> (by Intel manuals, I don't recall why) for things like spinlock loops, and
> using yield there would be bad.
>
The other thing is that sched_yield won't relax at all if you are the
only thing running, it will be a busy wait. So again, maybe not a great
fit for the idle loop either.
-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content. Register
by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
WARNING: multiple messages have this Message-ID (diff)
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Blaisorblade <blaisorblade@yahoo.it>
Cc: user-mode-linux-devel@lists.sourceforge.net,
Bodo Stroesser <bstroesser@fujitsu-siemens.com>,
akpm@osdl.org, jdike@addtoit.com, linux-kernel@vger.kernel.org
Subject: Re: [uml-devel] [patch 02/12] uml: cpu_relax fix
Date: Thu, 24 Mar 2005 13:09:41 +1100 [thread overview]
Message-ID: <42422165.20505@yahoo.com.au> (raw)
In-Reply-To: <200503240250.38153.blaisorblade@yahoo.it>
Blaisorblade wrote:
> On Wednesday 23 March 2005 18:09, Bodo Stroesser wrote:
>
>>blaisorblade@yahoo.it wrote:
>>
>>>Use rep_nop instead of barrier for cpu_relax, following $(SUBARCH)'s
>>>doing that (i.e. i386 and x86_64).
>>
>>IIRC, Jeff had the idea, to use sched_yield() for this (from a discussion
>>on #uml).
>
> Hmm, makes sense, but this is to benchmark well... I remember from early
> discussions on 2.6 scheduler that using sched_yield might decrease
> performance (IIRC starve the calling application).
>
Typically, for places where cpu_relax is used, sched_yield would be
a poor fit. So yes it could easily reduce performance.
> Also, that call should be put inside the idle loop, not for cpu_relax, which
> is very different, since it is used (for instance) in kernel/spinlock.c for
> spinlocks, and in such things. The "Pause" opcode is explicitly recommended
> (by Intel manuals, I don't recall why) for things like spinlock loops, and
> using yield there would be bad.
>
The other thing is that sched_yield won't relax at all if you are the
only thing running, it will be a busy wait. So again, maybe not a great
fit for the idle loop either.
next prev parent reply other threads:[~2005-03-24 2:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-22 16:21 [uml-devel] [patch 02/12] uml: cpu_relax fix blaisorblade
2005-03-22 16:21 ` blaisorblade
2005-03-23 17:09 ` [uml-devel] " Bodo Stroesser
2005-03-23 17:09 ` Bodo Stroesser
2005-03-24 1:50 ` Blaisorblade
2005-03-24 1:50 ` Blaisorblade
2005-03-24 2:02 ` Andrew Morton
2005-03-24 2:02 ` Andrew Morton
2005-03-24 2:09 ` Nick Piggin [this message]
2005-03-24 2:09 ` Nick Piggin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42422165.20505@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@osdl.org \
--cc=blaisorblade@yahoo.it \
--cc=bstroesser@fujitsu-siemens.com \
--cc=jdike@addtoit.com \
--cc=linux-kernel@vger.kernel.org \
--cc=user-mode-linux-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.