From: Andrea Arcangeli <andrea@suse.de>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.6.5-rc3-aa1
Date: Wed, 31 Mar 2004 06:08:59 +0200 [thread overview]
Message-ID: <20040331040859.GB2143@dualathlon.random> (raw)
In-Reply-To: <20040330194149.4f1451bc.akpm@osdl.org>
On Tue, Mar 30, 2004 at 07:41:49PM -0800, Andrew Morton wrote:
> Andrea Arcangeli <andrea@suse.de> wrote:
> >
> > In the meantime this is already mergeable in -mm if Andrew is
> > interested.
>
> It's a bit early for that, I feel. I'd like to see thing settle down a
> little more at your end first, then see that Rajesh, Hugh and if possible
no problem in settling it down more on my end.
> Ingo have had a good go through everything.
the thing isn't changing much anymore, there are only a few lines
fixes across the last updates.
the mprotect merging won't be as small, but it should not be more than
an hundred lines rewrite and it's orthogonal with the rest of the
changes. I plan to complete it before the end of the week.
Keep in mind this whole thing is going in production in a matter of a
week, so please test and review now. I'm uncertain if to add the
mprotect merging to the production tree after I completed it, I don't
see it as a requirement, infact I believe mprotect has always been more
important for file mappings than anonymous memory (I know this is
certainly the case for some big app where merging file mappings in
mprotect actually would help a bit too). At this point in time unless I
get a complaint for a real app I'll probably avoid any further change to
avoid invalidating the current testing. So I may keep the mprotect
merging in a separate patch.
I'm _very_ confortable that whatever might go wrong with this new code
that I cannot imagine right now, it'll always be a lot better than the
stuff that we know goes wrong with rmap or/and 4:4.
> We have a way to go yet. Once I've dumped a lot of the current pending
> stuff into 2.6.6-early we'll be in better shape.
I'd like to see the -mm writeback changes merged ASAP since they're the
most invasive from my point of view ;)
thanks.
next prev parent reply other threads:[~2004-03-31 4:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-31 3:09 2.6.5-rc3-aa1 Andrea Arcangeli
2004-03-31 3:41 ` 2.6.5-rc3-aa1 Andrew Morton
2004-03-31 4:08 ` Andrea Arcangeli [this message]
2004-03-31 19:16 ` 2.6.5-rc3-aa1 Bongani Hlope
2004-03-31 21:22 ` 2.6.5-rc3-aa1 Andrea Arcangeli
2004-04-01 4:47 ` 2.6.5-rc3-aa1 Bongani Hlope
2004-04-01 9:57 ` 2.6.5-rc3-aa1 Marc-Christian Petersen
2004-04-01 10:21 ` 2.6.5-rc3-aa1 Marc-Christian Petersen
2004-04-01 19:00 ` 2.6.5-rc3-aa1 Bongani Hlope
2004-04-01 13:38 ` 2.6.5-rc3-aa1 Andrea Arcangeli
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=20040331040859.GB2143@dualathlon.random \
--to=andrea@suse.de \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.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
all inboxes | Powered by JetHome®