From: Andrea Arcangeli <andrea@suse.de>
To: Linus Torvalds <torvalds@osdl.org>
Cc: "David S. Miller" <davem@davemloft.net>,
linux-kernel@vger.kernel.org, tglx@linutronix.de, akpm@osdl.org
Subject: Re: VM fixes [4/4]
Date: Sat, 25 Dec 2004 03:27:21 +0100 [thread overview]
Message-ID: <20041225022721.GR13747@dualathlon.random> (raw)
In-Reply-To: <Pine.LNX.4.58.0412241533170.2353@ppc970.osdl.org>
On Fri, Dec 24, 2004 at 03:41:37PM -0800, Linus Torvalds wrote:
>
>
> On Fri, 24 Dec 2004, Andrea Arcangeli wrote:
> >
> > If those old cpus really supported smp in linux, then fixing this bit is
> > trivial, just change it to short. Do they support short at least?
>
> It's not even about SMP. "byte" and "short" are not IRQ-safe or even
> preemption-safe (although I guess alpha doesn't support CONFIG_PREEMPT
> right now anyway) on pre-byte-access alphas.
What I meant in this specific case being UP w/o preempt is enough to be
safe, because irq cannot modify memdie/used_math/oomadj. Only normal
kernel context can (or at most used_math can be modified by an exception
running on top of normal kernel context that we know doesn't touch
memdie/oomadj).
If these variables were to be modified from irqs then of course being UP
w/o preempt wouldn't be enough. But it was enough in this specific case.
So the only trouble here is SMP or PREEMPT.
> Just don't do it. Maybe we'll never see another chip try what alpha did
> (it was arguably the single biggest mistake the early alphas had, and
> caused tons of system design trouble), but just use an "int".
>
> That said, I'd suggest putting it in the thread structure instead. We
> already have thread-safe flags there, just use one of the bits. Yes,
> you'll need to use locked accesses to set it, but hey, how often does
> something like this get set anyway? And then you just do ti _right_, using
> set_thread_flag/clear_thread_flag etc..
Actually I wonder if used_math should really become a PF_USED_MATH and
not the set_thread_flag/clear_thread_flag type of bitflag. The PF_ flags
have the property that they can only be modified by the "current" task.
But the current "short used_math" has the same requirement of the
PF_USED_MATH in this respect. So unless used_math is already racy (since
it's not being modified by locked ins), it should be correct to convert
it to a PF_ bitflag, which is not using locks.
memdie instead really should become a
set_thread_flags/clear_thread_flag (curently it's racy, while we set the
bitflag, the other cpu may be exiting already and we may be preventing
PF_EXITING or PF_DEAD to be set on a exited task with this current
race).
Note also that used_math is currently a short, it might not be a bug but
that's already misleading, it really shall be an int at the light of
your suggestions. I take the blame for making it worse (i.e. a char ;)
So my current plan is to make used_math a PF_USED_MATH, and memdie a
TIF_MEMDIE. And of course oomtaskadj an int (that one requires more than
1 bit of info ;). This change should be optimal for all archs and it
will fix the alpha arch with smp or preempt enabled on older cpus too.
I'd like to make those changes incrementally to the other patches I
already posted, so I avoid rejects fixing work (more than one patch
modified that code).
next prev parent reply other threads:[~2004-12-25 2:28 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-24 17:41 VM fixes [4/4] Andrea Arcangeli
2004-12-24 18:01 ` David S. Miller
2004-12-24 18:22 ` Andrea Arcangeli
2004-12-24 20:55 ` David S. Miller
2004-12-24 21:25 ` William Lee Irwin III
2004-12-24 23:52 ` William Lee Irwin III
2004-12-24 23:55 ` David S. Miller
2004-12-24 23:41 ` Linus Torvalds
2004-12-25 2:27 ` Andrea Arcangeli [this message]
2004-12-25 3:24 ` VM fixes [PF_MEMDIE to TIF_MEMDIE] [5/4] Andrea Arcangeli
2004-12-25 14:53 ` VM fixes [->used_math to PF_USED_MATH] [6/4] Andrea Arcangeli
2004-12-27 7:03 ` Andy Isaacson
2005-01-02 15:41 ` Andrea Arcangeli
2005-01-08 17:17 ` William Lee Irwin III
2004-12-25 0:06 ` VM fixes [4/4] Mitchell Blank Jr
2004-12-25 2:37 ` Andrea Arcangeli
2004-12-24 23:32 ` Linus Torvalds
2004-12-27 13:38 ` Rik van Riel
2004-12-28 9:42 ` Thomas Gleixner
2005-01-02 15:51 ` Andrea Arcangeli
2005-01-02 16:44 ` Rik van Riel
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=20041225022721.GR13747@dualathlon.random \
--to=andrea@suse.de \
--cc=akpm@osdl.org \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=torvalds@osdl.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox