mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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.

  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®