linux-kernel - Re: [PATCH] cache last free vmap_area to avoid restarting beginning

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 18 May 2010 14:44:27 +0100
From:	Steven Whitehouse <swhiteho@...hat.com>
To:	Nick Piggin <npiggin@...e.de>
Cc:	Minchan Kim <minchan.kim@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] cache last free vmap_area to avoid restarting beginning

Hi,

On Mon, 2010-05-17 at 13:42 +0100, Steven Whitehouse wrote:
> Hi,
> 
> On Thu, 2010-05-06 at 02:16 +1000, Nick Piggin wrote:
> > On Wed, May 05, 2010 at 01:48:48PM +0100, Steven Whitehouse wrote:
> > > Hi,
> > > 
> > > On Mon, 2010-05-03 at 02:29 +0900, Minchan Kim wrote:
> > > > Hi, Steven. 
> > > > 
> > > > Sorry for lazy response.
> > > > I wanted to submit the patch which implement Nick's request whole.
> > > > And unfortunately, I am so busy now. 
> > > > But if it's urgent, I want to submit this one firstly and 
> > > > at next version, maybe I will submit remained TODO things 
> > > > after middle of May.
> > > > 
> > > > I think this patch can't make regression other usages.
> > > > Nick. What do you think about?
> > > > 
> > > I guess the question is whether the remaining items are essential for
> > > correct functioning of this patch, or whether they are "it would be nice
> > > if" items. I suspect that they are the latter (I'm not a VM expert, but
> > > from the brief descriptions it looks like that to me) in which case I'd
> > > suggest send the currently existing patch first and the following up
> > > with the remaining changes later.
> > > 
> > > We have got a nice speed up with your current patch and so far as I'm
> > > aware not introduced any new bugs or regressions with it.
> > > 
> > > Nick, does that sound ok?
> > 
> > Just got around to looking at it again. I definitely agree we need to
> > fix the regression, however I'm concerned about introducing other
> > possible problems while doing that.
> > 
> > The following patch should (modulo bugs, but it's somewhat tested) give
> > no difference in the allocation patterns, so won't introduce virtual
> > memory layout changes.
> > 
> > Any chance you could test it?
> > 
> 
> Apologies for the delay. I tried the patch on my test box and it worked
> perfectly ok. When the original test was tried which triggered the
> investigation in the first place, it failed to boot. Since that box is
> remote and with limited remote console access, all I've been able to
> find out is "it didn't work" which isn't very helpful.
> 
> I'm currently trying to figure out how we can work out whats wrong. It
> isn't at all certain that it is an issue with this patch - it could be
> almost anything :(
> 
> Steve.
> 
> 

Further tests show that exactly the same kernel, without that single
patch works ok, and but that with the patch we get the crash on boot. We
are trying to arrange for better console access to the test box (which
is remote) and will report back if we manage that and capture any
output,

Steve.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/