On Tue, Apr 24, 2007 at 10:55:45AM -0700, Christoph Lameter wrote:
> On Tue, 24 Apr 2007, Siddha, Suresh B wrote:
> > yes, we were planning to move this to a different percpu section, where
> > all the elements in this new section will be cacheline aligned(both
> > at the start, aswell as end)
>
On Tue, 24 Apr 2007, Siddha, Suresh B wrote:
> On Tue, Apr 24, 2007 at 10:47:45AM -0700, Christoph Lameter wrote:
> > On Tue, 24 Apr 2007, Siddha, Suresh B wrote:
> > > Anyhow, this is a straight forward optimization and needs to be done. Do
> > > you
> > > have any specific concerns?
> >
> >
On Tue, Apr 24, 2007 at 10:47:45AM -0700, Christoph Lameter wrote:
> On Tue, 24 Apr 2007, Siddha, Suresh B wrote:
> > Anyhow, this is a straight forward optimization and needs to be done. Do you
> > have any specific concerns?
>
> Yes there should not be contention on per cpu data in principle.
On Tue, 24 Apr 2007, Siddha, Suresh B wrote:
> > .5% is usually in the noise ratio. Are you consistently seeing an
> > improvement or is that sporadic?
>
> No. This is consistent. I am waiting for the perf data on a much much bigger
> NUMA box.
>
> Anyhow, this is a straight forward
On Tue, Apr 24, 2007 at 10:39:48AM -0700, Christoph Lameter wrote:
> On Fri, 20 Apr 2007, Siddha, Suresh B wrote:
>
> > > Last I checked it was workload-dependent, but there were things that
> > > hammer it. I mostly know of the remote wakeup issue, but there could
> > > be other things besides
On Fri, 20 Apr 2007, Siddha, Suresh B wrote:
> > Last I checked it was workload-dependent, but there were things that
> > hammer it. I mostly know of the remote wakeup issue, but there could
> > be other things besides wakeups that do it, too.
>
> remote wakeup was the main issue and the 0.5%
On Fri, Apr 20, 2007 at 12:24:17PM -0700, Christoph Lameter wrote:
> On Wed, 18 Apr 2007, William Lee Irwin III wrote:
>
> >
> > Mark the runqueues cacheline_aligned_in_smp to avoid false sharing.
>
> False sharing for a per cpu data structure? Are we updating that
> structure from other
On Fri, Apr 20, 2007 at 01:03:22PM -0700, William Lee Irwin III wrote:
> On Fri, 20 Apr 2007, William Lee Irwin III wrote:
> >> I'm not really convinced it's all that worthwhile of an optimization,
> >> essentially for the same reasons as you, but presumably there's a
> >> benchmark result
On Fri, Apr 20, 2007 at 12:24:17PM -0700, Christoph Lameter wrote:
On Wed, 18 Apr 2007, William Lee Irwin III wrote:
Mark the runqueues cacheline_aligned_in_smp to avoid false sharing.
False sharing for a per cpu data structure? Are we updating that
structure from other
On Fri, Apr 20, 2007 at 01:03:22PM -0700, William Lee Irwin III wrote:
On Fri, 20 Apr 2007, William Lee Irwin III wrote:
I'm not really convinced it's all that worthwhile of an optimization,
essentially for the same reasons as you, but presumably there's a
benchmark result somewhere that
On Fri, 20 Apr 2007, Siddha, Suresh B wrote:
Last I checked it was workload-dependent, but there were things that
hammer it. I mostly know of the remote wakeup issue, but there could
be other things besides wakeups that do it, too.
remote wakeup was the main issue and the 0.5%
On Tue, Apr 24, 2007 at 10:39:48AM -0700, Christoph Lameter wrote:
On Fri, 20 Apr 2007, Siddha, Suresh B wrote:
Last I checked it was workload-dependent, but there were things that
hammer it. I mostly know of the remote wakeup issue, but there could
be other things besides wakeups that
On Tue, 24 Apr 2007, Siddha, Suresh B wrote:
.5% is usually in the noise ratio. Are you consistently seeing an
improvement or is that sporadic?
No. This is consistent. I am waiting for the perf data on a much much bigger
NUMA box.
Anyhow, this is a straight forward optimization and
On Tue, Apr 24, 2007 at 10:47:45AM -0700, Christoph Lameter wrote:
On Tue, 24 Apr 2007, Siddha, Suresh B wrote:
Anyhow, this is a straight forward optimization and needs to be done. Do you
have any specific concerns?
Yes there should not be contention on per cpu data in principle. The
On Tue, 24 Apr 2007, Siddha, Suresh B wrote:
On Tue, Apr 24, 2007 at 10:47:45AM -0700, Christoph Lameter wrote:
On Tue, 24 Apr 2007, Siddha, Suresh B wrote:
Anyhow, this is a straight forward optimization and needs to be done. Do
you
have any specific concerns?
Yes there should
On Tue, Apr 24, 2007 at 10:55:45AM -0700, Christoph Lameter wrote:
On Tue, 24 Apr 2007, Siddha, Suresh B wrote:
yes, we were planning to move this to a different percpu section, where
all the elements in this new section will be cacheline aligned(both
at the start, aswell as end)
I would
* William Lee Irwin III <[EMAIL PROTECTED]> wrote:
>> Suppose a table of nice weights like the following is tuned via
>> /proc/:
>> -20 21 0 1
>> -1 2 19 0.0476
> > Essentially 1/(n+1) when n >= 0 and 1-n when n < 0.
On Sat, Apr 21, 2007
Peter Williams wrote:
Ingo Molnar wrote:
* Peter Williams <[EMAIL PROTECTED]> wrote:
I retract this suggestion as it's a very bad idea. It introduces the
possibility of starvation via the poor sods at the bottom of the
queue having their "on CPU" forever postponed and we all know that
even
Ingo Molnar wrote:
* Peter Williams <[EMAIL PROTECTED]> wrote:
I retract this suggestion as it's a very bad idea. It introduces the
possibility of starvation via the poor sods at the bottom of the queue
having their "on CPU" forever postponed and we all know that even the
smallest
* William Lee Irwin III <[EMAIL PROTECTED]> wrote:
> I suppose this is a special case of the dreaded priority inversion.
> What of, say, nice 19 tasks holding fs semaphores and/or mutexes that
> nice -19 tasks are waiting to acquire? Perhaps rt_mutex should be the
> default mutex
On Sat, Apr 21, 2007 at 09:54:01AM +0200, Ingo Molnar wrote:
> In practice they can starve a bit when one renices thousands of tasks,
> so i was thinking about the following special-case: to at least make
> them easily killable: if a nice 0 task sends a SIGKILL to a nice 19 task
> then we could
Peter Williams wrote:
Peter Williams wrote:
Ingo Molnar wrote:
your suggestion concentrates on the following scenario: if a task
happens to schedule in an 'unlucky' way and happens to hit a busy
period while there are many idle periods. Unless i misunderstood your
suggestion, that is the
* Peter Williams <[EMAIL PROTECTED]> wrote:
> I retract this suggestion as it's a very bad idea. It introduces the
> possibility of starvation via the poor sods at the bottom of the queue
> having their "on CPU" forever postponed and we all know that even the
> smallest possibility of
Peter Williams wrote:
William Lee Irwin III wrote:
William Lee Irwin III wrote:
On Sat, Apr 21, 2007 at 10:23:07AM +1000, Peter Williams wrote:
If some form of precise timer was used (instead) to trigger
pre-emption then, where there is more than one task with the same
expected "on CPU" time,
Peter Williams wrote:
William Lee Irwin III wrote:
William Lee Irwin III wrote:
On Sat, Apr 21, 2007 at 10:23:07AM +1000, Peter Williams wrote:
If some form of precise timer was used (instead) to trigger
pre-emption then, where there is more than one task with the same
expected on CPU time,
* Peter Williams [EMAIL PROTECTED] wrote:
I retract this suggestion as it's a very bad idea. It introduces the
possibility of starvation via the poor sods at the bottom of the queue
having their on CPU forever postponed and we all know that even the
smallest possibility of starvation
Peter Williams wrote:
Peter Williams wrote:
Ingo Molnar wrote:
your suggestion concentrates on the following scenario: if a task
happens to schedule in an 'unlucky' way and happens to hit a busy
period while there are many idle periods. Unless i misunderstood your
suggestion, that is the
On Sat, Apr 21, 2007 at 09:54:01AM +0200, Ingo Molnar wrote:
In practice they can starve a bit when one renices thousands of tasks,
so i was thinking about the following special-case: to at least make
them easily killable: if a nice 0 task sends a SIGKILL to a nice 19 task
then we could
* William Lee Irwin III [EMAIL PROTECTED] wrote:
I suppose this is a special case of the dreaded priority inversion.
What of, say, nice 19 tasks holding fs semaphores and/or mutexes that
nice -19 tasks are waiting to acquire? Perhaps rt_mutex should be the
default mutex implementation.
Ingo Molnar wrote:
* Peter Williams [EMAIL PROTECTED] wrote:
I retract this suggestion as it's a very bad idea. It introduces the
possibility of starvation via the poor sods at the bottom of the queue
having their on CPU forever postponed and we all know that even the
smallest possibility
Peter Williams wrote:
Ingo Molnar wrote:
* Peter Williams [EMAIL PROTECTED] wrote:
I retract this suggestion as it's a very bad idea. It introduces the
possibility of starvation via the poor sods at the bottom of the
queue having their on CPU forever postponed and we all know that
even the
* William Lee Irwin III [EMAIL PROTECTED] wrote:
Suppose a table of nice weights like the following is tuned via
/proc/:
-20 21 0 1
-1 2 19 0.0476
Essentially 1/(n+1) when n = 0 and 1-n when n 0.
On Sat, Apr 21, 2007 at 10:57:29AM
William Lee Irwin III wrote:
William Lee Irwin III wrote:
This essentially doesn't look correct because while you want to enforce
the CPU bandwidth allocation, this doesn't have much to do with that
apart from the CPU bandwidth appearing as a term. It's more properly
a rate of service as
William Lee Irwin III wrote:
>> This essentially doesn't look correct because while you want to enforce
>> the CPU bandwidth allocation, this doesn't have much to do with that
>> apart from the CPU bandwidth appearing as a term. It's more properly
>> a rate of service as opposed to a time at which
William Lee Irwin III wrote:
On Fri, Apr 20, 2007 at 10:10:45AM +1000, Peter Williams wrote:
I have a suggestion I'd like to make that addresses both nice and
fairness at the same time. As I understand the basic principle behind
this scheduler it to work out a time by which a task should make
On Fri, 20 Apr 2007, William Lee Irwin III wrote:
>> I'm not really convinced it's all that worthwhile of an optimization,
>> essentially for the same reasons as you, but presumably there's a
>> benchmark result somewhere that says it matters. I've just not seen it.
On Fri, Apr 20, 2007 at
On Fri, 20 Apr 2007, William Lee Irwin III wrote:
> I'm not really convinced it's all that worthwhile of an optimization,
> essentially for the same reasons as you, but presumably there's a
> benchmark result somewhere that says it matters. I've just not seen it.
If it is true that we frequently
Fri, Apr 20, 2007 at 12:24:17PM -0700, Christoph Lameter wrote:
>>> False sharing for a per cpu data structure? Are we updating that
>>> structure from other processors?
On Fri, 20 Apr 2007, William Lee Irwin III wrote:
>> Primarily in the load balancer, but also in wakeups.
On Fri, Apr 20,
On Fri, 20 Apr 2007, William Lee Irwin III wrote:
> On Wed, 18 Apr 2007, William Lee Irwin III wrote:
> >>
> >> Mark the runqueues cacheline_aligned_in_smp to avoid false sharing.
>
> On Fri, Apr 20, 2007 at 12:24:17PM -0700, Christoph Lameter wrote:
> > False sharing for a per cpu data
On Wed, 18 Apr 2007, William Lee Irwin III wrote:
>>
>> Mark the runqueues cacheline_aligned_in_smp to avoid false sharing.
On Fri, Apr 20, 2007 at 12:24:17PM -0700, Christoph Lameter wrote:
> False sharing for a per cpu data structure? Are we updating that
> structure from other
On Wed, 18 Apr 2007, William Lee Irwin III wrote:
>
> Mark the runqueues cacheline_aligned_in_smp to avoid false sharing.
False sharing for a per cpu data structure? Are we updating that
structure from other processors?
-
To unsubscribe from this list: send the line "unsubscribe
* Peter Williams <[EMAIL PROTECTED]> wrote:
> BTW Given that I'm right and dynamic priorities have been dispensed
> with what do you intend exporting (in their place) to user space for
> display by top and similar?
well i thought of only displaying static ones, i.e. like the current
patch
Peter Williams wrote:
Ingo Molnar wrote:
- bugfix: use constant offset factor for nice levels instead of
sched_granularity_ns. Thus nice levels work even if someone sets
sched_granularity_ns to 0. NOTE: nice support is still naive, i'll
address the many nice level related
On Fri, Apr 20, 2007 at 10:10:45AM +1000, Peter Williams wrote:
> I have a suggestion I'd like to make that addresses both nice and
> fairness at the same time. As I understand the basic principle behind
> this scheduler it to work out a time by which a task should make it onto
> the CPU and
Peter Williams wrote:
Ingo Molnar wrote:
* Peter Williams <[EMAIL PROTECTED]> wrote:
- bugfix: use constant offset factor for nice levels instead of
sched_granularity_ns. Thus nice levels work even if someone sets
sched_granularity_ns to 0. NOTE: nice support is still naive, i'll
Ingo Molnar wrote:
* Peter Williams <[EMAIL PROTECTED]> wrote:
- bugfix: use constant offset factor for nice levels instead of
sched_granularity_ns. Thus nice levels work even if someone sets
sched_granularity_ns to 0. NOTE: nice support is still naive, i'll
address the many nice level
On Fri, Apr 20, 2007 at 04:02:41PM +1000, Peter Williams wrote:
> Willy Tarreau wrote:
> >On Fri, Apr 20, 2007 at 10:10:45AM +1000, Peter Williams wrote:
> >>Ingo Molnar wrote:
> >>>- bugfix: use constant offset factor for nice levels instead of
> >>> sched_granularity_ns. Thus nice levels work
* Peter Williams <[EMAIL PROTECTED]> wrote:
> > - bugfix: use constant offset factor for nice levels instead of
> > sched_granularity_ns. Thus nice levels work even if someone sets
> > sched_granularity_ns to 0. NOTE: nice support is still naive, i'll
> > address the many nice level
Peter Williams wrote:
Willy Tarreau wrote:
On Fri, Apr 20, 2007 at 10:10:45AM +1000, Peter Williams wrote:
Ingo Molnar wrote:
- bugfix: use constant offset factor for nice levels instead of
sched_granularity_ns. Thus nice levels work even if someone sets
sched_granularity_ns to 0. NOTE:
Willy Tarreau wrote:
On Fri, Apr 20, 2007 at 10:10:45AM +1000, Peter Williams wrote:
Ingo Molnar wrote:
- bugfix: use constant offset factor for nice levels instead of
sched_granularity_ns. Thus nice levels work even if someone sets
sched_granularity_ns to 0. NOTE: nice support is still
Willy Tarreau wrote:
On Fri, Apr 20, 2007 at 10:10:45AM +1000, Peter Williams wrote:
Ingo Molnar wrote:
- bugfix: use constant offset factor for nice levels instead of
sched_granularity_ns. Thus nice levels work even if someone sets
sched_granularity_ns to 0. NOTE: nice support is still
Peter Williams wrote:
Willy Tarreau wrote:
On Fri, Apr 20, 2007 at 10:10:45AM +1000, Peter Williams wrote:
Ingo Molnar wrote:
- bugfix: use constant offset factor for nice levels instead of
sched_granularity_ns. Thus nice levels work even if someone sets
sched_granularity_ns to 0. NOTE:
* Peter Williams [EMAIL PROTECTED] wrote:
- bugfix: use constant offset factor for nice levels instead of
sched_granularity_ns. Thus nice levels work even if someone sets
sched_granularity_ns to 0. NOTE: nice support is still naive, i'll
address the many nice level related
On Fri, Apr 20, 2007 at 04:02:41PM +1000, Peter Williams wrote:
Willy Tarreau wrote:
On Fri, Apr 20, 2007 at 10:10:45AM +1000, Peter Williams wrote:
Ingo Molnar wrote:
- bugfix: use constant offset factor for nice levels instead of
sched_granularity_ns. Thus nice levels work even if
Ingo Molnar wrote:
* Peter Williams [EMAIL PROTECTED] wrote:
- bugfix: use constant offset factor for nice levels instead of
sched_granularity_ns. Thus nice levels work even if someone sets
sched_granularity_ns to 0. NOTE: nice support is still naive, i'll
address the many nice level
Peter Williams wrote:
Ingo Molnar wrote:
* Peter Williams [EMAIL PROTECTED] wrote:
- bugfix: use constant offset factor for nice levels instead of
sched_granularity_ns. Thus nice levels work even if someone sets
sched_granularity_ns to 0. NOTE: nice support is still naive, i'll
* Peter Williams [EMAIL PROTECTED] wrote:
BTW Given that I'm right and dynamic priorities have been dispensed
with what do you intend exporting (in their place) to user space for
display by top and similar?
well i thought of only displaying static ones, i.e. like the current
patch does.
Peter Williams wrote:
Ingo Molnar wrote:
- bugfix: use constant offset factor for nice levels instead of
sched_granularity_ns. Thus nice levels work even if someone sets
sched_granularity_ns to 0. NOTE: nice support is still naive, i'll
address the many nice level related
On Fri, Apr 20, 2007 at 10:10:45AM +1000, Peter Williams wrote:
I have a suggestion I'd like to make that addresses both nice and
fairness at the same time. As I understand the basic principle behind
this scheduler it to work out a time by which a task should make it onto
the CPU and then
On Wed, 18 Apr 2007, William Lee Irwin III wrote:
Mark the runqueues cacheline_aligned_in_smp to avoid false sharing.
False sharing for a per cpu data structure? Are we updating that
structure from other processors?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Wed, 18 Apr 2007, William Lee Irwin III wrote:
Mark the runqueues cacheline_aligned_in_smp to avoid false sharing.
On Fri, Apr 20, 2007 at 12:24:17PM -0700, Christoph Lameter wrote:
False sharing for a per cpu data structure? Are we updating that
structure from other processors?
On Fri, 20 Apr 2007, William Lee Irwin III wrote:
On Wed, 18 Apr 2007, William Lee Irwin III wrote:
Mark the runqueues cacheline_aligned_in_smp to avoid false sharing.
On Fri, Apr 20, 2007 at 12:24:17PM -0700, Christoph Lameter wrote:
False sharing for a per cpu data structure? Are
Fri, Apr 20, 2007 at 12:24:17PM -0700, Christoph Lameter wrote:
False sharing for a per cpu data structure? Are we updating that
structure from other processors?
On Fri, 20 Apr 2007, William Lee Irwin III wrote:
Primarily in the load balancer, but also in wakeups.
On Fri, Apr 20, 2007 at
On Fri, 20 Apr 2007, William Lee Irwin III wrote:
I'm not really convinced it's all that worthwhile of an optimization,
essentially for the same reasons as you, but presumably there's a
benchmark result somewhere that says it matters. I've just not seen it.
If it is true that we frequently
On Fri, 20 Apr 2007, William Lee Irwin III wrote:
I'm not really convinced it's all that worthwhile of an optimization,
essentially for the same reasons as you, but presumably there's a
benchmark result somewhere that says it matters. I've just not seen it.
On Fri, Apr 20, 2007 at 12:44:55PM
William Lee Irwin III wrote:
On Fri, Apr 20, 2007 at 10:10:45AM +1000, Peter Williams wrote:
I have a suggestion I'd like to make that addresses both nice and
fairness at the same time. As I understand the basic principle behind
this scheduler it to work out a time by which a task should make
William Lee Irwin III wrote:
This essentially doesn't look correct because while you want to enforce
the CPU bandwidth allocation, this doesn't have much to do with that
apart from the CPU bandwidth appearing as a term. It's more properly
a rate of service as opposed to a time at which
William Lee Irwin III wrote:
William Lee Irwin III wrote:
This essentially doesn't look correct because while you want to enforce
the CPU bandwidth allocation, this doesn't have much to do with that
apart from the CPU bandwidth appearing as a term. It's more properly
a rate of service as
On Fri, Apr 20, 2007 at 10:10:45AM +1000, Peter Williams wrote:
> Ingo Molnar wrote:
> >
> > - bugfix: use constant offset factor for nice levels instead of
> > sched_granularity_ns. Thus nice levels work even if someone sets
> > sched_granularity_ns to 0. NOTE: nice support is still naive,
Ingo Molnar wrote:
- bugfix: use constant offset factor for nice levels instead of
sched_granularity_ns. Thus nice levels work even if someone sets
sched_granularity_ns to 0. NOTE: nice support is still naive, i'll
address the many nice level related suggestions in -v4.
I have a
Ingo Molnar wrote:
- bugfix: use constant offset factor for nice levels instead of
sched_granularity_ns. Thus nice levels work even if someone sets
sched_granularity_ns to 0. NOTE: nice support is still naive, i'll
address the many nice level related suggestions in -v4.
I have a
On Fri, Apr 20, 2007 at 10:10:45AM +1000, Peter Williams wrote:
Ingo Molnar wrote:
- bugfix: use constant offset factor for nice levels instead of
sched_granularity_ns. Thus nice levels work even if someone sets
sched_granularity_ns to 0. NOTE: nice support is still naive, i'll
* William Lee Irwin III <[EMAIL PROTECTED]> wrote:
> It appears to me that the following can be taken in for mainline (or
> rejected for mainline) independently of the rest of the cfs patch.
yeah - it's a patch written by Suresh, and this should already be in the
for-v2.6.22 -mm queue. See:
On Wed, Apr 18, 2007 at 07:50:17PM +0200, Ingo Molnar wrote:
> this is the third release of the CFS patchset (against v2.6.21-rc7), and
> can be downloaded from:
>http://redhat.com/~mingo/cfs-scheduler/
> this is a pure "fix reported regressions" release so there's much less
> churn:
>5
On Wed, Apr 18, 2007 at 07:50:17PM +0200, Ingo Molnar wrote:
this is the third release of the CFS patchset (against v2.6.21-rc7), and
can be downloaded from:
http://redhat.com/~mingo/cfs-scheduler/
this is a pure fix reported regressions release so there's much less
churn:
5 files
* William Lee Irwin III [EMAIL PROTECTED] wrote:
It appears to me that the following can be taken in for mainline (or
rejected for mainline) independently of the rest of the cfs patch.
yeah - it's a patch written by Suresh, and this should already be in the
for-v2.6.22 -mm queue. See:
76 matches
Mail list logo
