All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: Andi Kleen <andi@firstfloor.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Ingo Molnar <mingo@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC] Thread Migration Preemption
Date: Wed, 11 Jul 2007 00:57:15 -0400	[thread overview]
Message-ID: <20070711045715.GB4025@Krystal> (raw)
In-Reply-To: <20070706171159.GB8174@one.firstfloor.org>

* Andi Kleen (andi@firstfloor.org) wrote:
> On Fri, Jul 06, 2007 at 10:41:44AM -0400, Mathieu Desnoyers wrote:
> > I haven't thought about making it the default for kernel space
> > preemption, but yes, it would make sense.
> 
> Now it's too late -- getcpu() has infected the kernel everywhere.
> It would have made sense a few years ago.
> 
> 
> > ... getcpu()...
> 
> Hmm ok, although i suspect it's rare to assume that. But understood
> you don't want to audit all getcpu users because of this.
> 
> > using a short instead of an int on modern x86 will cause pipeline stalls
> > due to partial register use.
> 
> Sorry, that's totally bogus. Primarily because the access would be directly
> on memory and there is no partial register tracking there.
> 
> Besides pipeline stall is not the correct description on what would
> happen if you used a register, the worst you get is a single false dependency
> but no pipeline flush.
> 
> Besides the latest x86 cpus (C2, K8) don't have much trouble with these
> false dependencies in general.
> 

Yes, false dependency is what I meant. And hrm, yeah I guess that mostly
movzbl would be used to get the byte from memory and zero-extend, making
sure there is no false dependency.

> > usage, since it is followed by an unsigned long; gcc structure alignment
> 
> 
> > will put padding instead of the integer, which does not buy us anything
> 
> on i386 unsigned long is 4 bytes.
> 

Since we have, on i386:

        int                     preempt_count;  /* 0 => preemptable, <0 => BUG */
        int                     migrate_count;/* 0: can migrate, <0: BUG */
        mm_segment_t            addr_limit;     /* thread address space:

and:

typedef struct {
        unsigned long seg;
} mm_segment_t;

Turning migrate_count into a char would only put padding between
migrate_count and addr_limit. So I still do not see a clear improvement
in memory usage there... but I don't specially care about it being an
integer or a byte though :)

Mathieu


> -Andi

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

  reply	other threads:[~2007-07-11  4:57 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-05 21:51 [RFC] Thread Migration Preemption Mathieu Desnoyers
2007-07-05 22:46 ` Steven Rostedt
2007-07-06  6:12 ` Nick Piggin
2007-07-06 14:34   ` Mathieu Desnoyers
2007-07-06 14:34   ` Steven Rostedt
2007-07-06 15:43     ` Daniel Walker
2007-07-08  9:05     ` Nick Piggin
2007-07-10 23:39   ` Matt Mackall
2007-07-11  0:02     ` Nick Piggin
2007-07-11  0:36       ` Matt Mackall
2007-07-11  0:55         ` Mathieu Desnoyers
2007-07-11  1:15           ` Nick Piggin
2007-07-06 11:59 ` Andi Kleen
2007-07-06 14:41   ` Mathieu Desnoyers
2007-07-06 17:11     ` Andi Kleen
2007-07-11  4:57       ` Mathieu Desnoyers [this message]
2007-07-23 18:33 ` Ingo Molnar
  -- strict thread matches above, loose matches on Subject: below --
2007-07-06  6:02 Oleg Nesterov
2007-07-06 14:23 ` Mathieu Desnoyers
2007-07-06 14:56   ` Oleg Nesterov

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=20070711045715.GB4025@Krystal \
    --to=mathieu.desnoyers@polymtl.ca \
    --cc=andi@firstfloor.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rostedt@goodmis.org \
    /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.