[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1246608553.24965.2.camel@pc1117.cambridge.arm.com>
Date: Fri, 03 Jul 2009 09:09:13 +0100
From: Catalin Marinas <catalin.marinas@....com>
To: Ingo Molnar <mingo@...e.hu>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
git-commits-head@...r.kernel.org
Subject: Re: [PATCH] kmemleak: Mark nice +10
On Fri, 2009-07-03 at 09:00 +0200, Ingo Molnar wrote:
> * Catalin Marinas <catalin.marinas@....com> wrote:
>
> > On Wed, 2009-07-01 at 11:30 +0200, Ingo Molnar wrote:
> > > * Catalin Marinas <catalin.marinas@....com> wrote:
> > >
> > > > > The minimal fix below removes scan_yield() and adds a
> > > > > cond_resched() to the outmost (safe) place of the scanning
> > > > > thread. This solves the regression.
> > > >
> > > > With CONFIG_PREEMPT disabled it won't reschedule during the bss
> > > > scanning but I don't see this as a real issue (task stacks
> > > > scanning probably takes longer anyway).
> > >
> > > Yeah. I suspect one more cond_resched() could be added - i just
> > > didnt see an obvious place for it, given that scan_block() is being
> > > called with asymetric held-locks contexts.
> >
> > Now that your patch was merged, I propose adding a few more
> > cond_resched() calls, useful for the !PREEMPT case:
>
> note, please also merge the renicing fix you sent. I have it tested
> in tip:out-of-tree, attached below.
I have this patch in my kmemleak branch
(http://www.linux-arm.org/git?p=linux-2.6.git;a=shortlog;h=kmemleak)
which I plan to push to Linus, only that I was waiting to accumulate a
few more patches (to avoid sending too many pull requests).
I'll fix the scan_mutex lock as well, following comments and send a pull
request tonight.
Thanks.
--
Catalin
--
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/
Powered by blists - more mailing lists