[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130813050213.GA2869@moon>
Date: Tue, 13 Aug 2013 09:02:13 +0400
From: Cyrill Gorcunov <gorcunov@...il.com>
To: Andy Lutomirski <luto@...capital.net>
Cc: Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, xemul@...allels.com, mpm@...enic.com,
xiaoguangrong@...ux.vnet.ibm.com, mtosatti@...hat.com,
kosaki.motohiro@...il.com, sfr@...b.auug.org.au,
peterz@...radead.org, aneesh.kumar@...ux.vnet.ibm.com,
Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [patch 2/2] [PATCH] mm: Save soft-dirty bits on file pages
On Mon, Aug 12, 2013 at 03:28:06PM -0700, Andy Lutomirski wrote:
> >
> > You could have #undefed _mfrob and __frob after using them, but whatever.
Sure, for some reason I forgot to do that. Will send update on top.
> > I saved this patch to wave at the x86 guys for 3.12. I plan to merge
> > mm-save-soft-dirty-bits-on-file-pages.patch for 3.11.
> >
> >> Guys, is there a reason for "if _PAGE_BIT_FILE < _PAGE_BIT_PROTNONE"
> >> test present in this pgtable-2level.h file at all? I can't imagine
> >> where it can be false on x86.
> >
> > I doubt if "Guys" read this. x86 maintainers cc'ed.
Thanks!
> > +#define _mfrob(v,r,m,l) ((((v) >> (r)) & (m)) << (l))
> > +#define __frob(v,r,l) (((v) >> (r)) << (l))
> > +
> > #ifdef CONFIG_MEM_SOFT_DIRTY
>
> If I'm understanding this right, the idea is to take the bits in the
> range a..b of v and stick them at c..d, where a-b == c-d. Would it
> make sense to change this to look something like
>
> #define __frob(v, inmsb, inlsb, outlsb) ((v >> inlsb) & ((1<<(inmsb -
> inlsb + 1)-1) << outlsb)
There is a case when you don't need a mask completely. And because this
pte conversion is on hot path and time critical I kept generated code
as it was (even if that lead to slightly less clear source code).
> For extra fun, there could be an __unfrob macro that takes the same
> inmsg, inlsb, outlsb parameters but undoes it so that it's (more)
> clear that the operations that are supposed to be inverses are indeed
> inverses.
--
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