On Tue, Aug 13, 2013 at 09:43:23AM -0700, H. Peter Anvin wrote:
> On 08/13/2013 08:37 AM, Cyrill Gorcunov wrote:
> >>
> >> Does it actually matter, generated-code-wise, or is the compiler smart
> >> enough to figure it out? The reason I'm asking is because it makes the
> >
> > gcc-4.7.2 is smart
On 08/13/2013 08:37 AM, Cyrill Gorcunov wrote:
>>
>> Does it actually matter, generated-code-wise, or is the compiler smart
>> enough to figure it out? The reason I'm asking is because it makes the
>
> gcc-4.7.2 is smart enough to suppress useless masking (ie ((1u << 31) - 1))
> completely but I
On Tue, Aug 13, 2013 at 08:14:39AM -0700, H. Peter Anvin wrote:
> On 08/12/2013 10:02 PM, Cyrill Gorcunov wrote:
> >
> > 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 lea
On 08/12/2013 10:02 PM, Cyrill Gorcunov wrote:
>
> 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).
>
Does it actually matter, genera
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-s
On Mon, 12 Aug 2013 15:28:06 -0700 Andy Lutomirski wrote:
> > +#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 b
On Mon, Aug 12, 2013 at 2:57 PM, Andrew Morton
wrote:
> On Thu, 8 Aug 2013 18:51:20 +0400 Cyrill Gorcunov wrote:
>
>> On Wed, Aug 07, 2013 at 01:28:12PM -0700, Andrew Morton wrote:
>> >
>> > Good god.
>> >
>> > I wonder if these can be turned into out-of-line functions in some form
>> > which hum
On Thu, 8 Aug 2013 18:51:20 +0400 Cyrill Gorcunov wrote:
> On Wed, Aug 07, 2013 at 01:28:12PM -0700, Andrew Morton wrote:
> >
> > Good god.
> >
> > I wonder if these can be turned into out-of-line functions in some form
> > which humans can understand.
> >
> > or
> >
> > #define pte_to_pgoff(
On Wed, Aug 07, 2013 at 01:28:12PM -0700, Andrew Morton wrote:
>
> Good god.
>
> I wonder if these can be turned into out-of-line functions in some form
> which humans can understand.
>
> or
>
> #define pte_to_pgoff(pte)
> frob(pte, PTE_FILE_SHIFT1, PTE_FILE_BITS1) +
> frob(PTE_FILE
On Wed, Aug 07, 2013 at 01:28:12PM -0700, Andrew Morton wrote:
>
> Good god.
>
> I wonder if these can be turned into out-of-line functions in some form
> which humans can understand.
>
> or
>
> #define pte_to_pgoff(pte)
> frob(pte, PTE_FILE_SHIFT1, PTE_FILE_BITS1) +
> frob(PTE_FILE
On Wed, 31 Jul 2013 00:41:56 +0400 Cyrill Gorcunov wrote:
> +#define pte_to_pgoff(pte)\
> + pte).pte_low >> (PTE_FILE_SHIFT1)) \
> + & ((1U << PTE_FILE_BITS1) - 1))) \
> + + pte
On 07/31/2013 12:41 AM, Cyrill Gorcunov wrote:
> Andy reported that if file page get reclaimed we loose soft-dirty bit
> if it was there, so save _PAGE_BIT_SOFT_DIRTY bit when page address
> get encoded into pte entry. Thus when #pf happens on such non-present
> pte we can restore it back.
>
> Re
Andy reported that if file page get reclaimed we loose soft-dirty bit
if it was there, so save _PAGE_BIT_SOFT_DIRTY bit when page address
get encoded into pte entry. Thus when #pf happens on such non-present
pte we can restore it back.
Reported-by: Andy Lutomirski
Signed-off-by: Cyrill Gorcunov
13 matches
Mail list logo
