Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1262487

Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE)

From Andy Lutomirski <luto@amacapital.net>
Newsgroups linux.kernel
Subject Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE)
Date 2015-11-04 19:30 +0100
Message-ID <qraYN-411-5@gated-at.bofh.it> (permalink)
References <qqV3I-27u-7@gated-at.bofh.it> <qqVdo-2aG-3@gated-at.bofh.it> <qqXfb-3wk-3@gated-at.bofh.it> <qqZh1-4OT-5@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Tue, Nov 3, 2015 at 9:50 PM, Daniel Micay <danielmicay@gmail.com> wrote:
>> Does this set the write protect bit?
>>
>> What happens on architectures without hardware dirty tracking?
>
> It's supposed to avoid needing page faults when the data is accessed
> again, but it can just be implemented via page faults on architectures
> without a way to check for access or writes. MADV_DONTNEED is also a
> valid implementation of MADV_FREE if it comes to that (which is what it
> does on swapless systems for now).

I wonder whether arches without the requisite tracking should just
turn it off.  While it might be faster than MADV_DONTNEED or munmap on
those arches, it doesn't really deserve to be faster.

>
>> Using the dirty bit for these semantics scares me.  This API creates a
>> page that can have visible nonzero contents and then can
>> asynchronously and magically zero itself thereafter.  That makes me
>> nervous.  Could we use the accessed bit instead?  Then the observable
>> semantics would be equivalent to having MADV_FREE either zero the page
>> or do nothing, except that it doesn't make up its mind until the next
>> read.
>
> FWIW, those are already basically the semantics provided by GCC and LLVM
> for data the compiler considers uninitialized (they could be more
> aggressive since C just says it's undefined, but in practice they allow
> it but can produce inconsistent results even if it isn't touched).
>
> http://llvm.org/docs/LangRef.html#undefined-values

But C isn't the only thing in the world.  Also, I think that a C
optimizer should be free to turn:

if ([complicated condition])
  *ptr = 1;

into:

if (*ptr != 1 && [complicated condition])
  *ptr = 1;

as long as [complicated condition] has no side effects.  The MADV_FREE
semantics in this patch set break that.

>
> It doesn't seem like there would be an advantage to checking if the data
> was written to vs. whether it was accessed if checking for both of those
> is comparable in performance. I don't know enough about that.

I'd imagine that there would be no performance difference whatsoever
on hardware that has a real accessed bit.  The only thing that changes
is the choice of which bit to use.

>
>>> +                       ptent = pte_mkold(ptent);
>>> +                       ptent = pte_mkclean(ptent);
>>> +                       set_pte_at(mm, addr, pte, ptent);
>>> +                       tlb_remove_tlb_entry(tlb, pte, addr);
>>
>> It looks like you are flushing the TLB.  In a multithreaded program,
>> that's rather expensive.  Potentially silly question: would it be
>> better to just zero the page immediately in a multithreaded program
>> and then, when swapping out, check the page is zeroed and, if so, skip
>> swapping it out?  That could be done without forcing an IPI.
>
> In the common case it will be passed many pages by the allocator. There
> will still be a layer of purging logic on top of MADV_FREE but it can be
> much thinner than the current workarounds for MADV_DONTNEED. So the
> allocator would still be coalescing dirty ranges and only purging when
> the ratio of dirty:clean pages rises above some threshold. It would be
> able to weight the largest ranges for purging first rather than logic
> based on stuff like aging as is used for MADV_DONTNEED.
>

With enough pages at once, though, munmap would be fine, too.

Maybe what's really needed is a MADV_FREE variant that takes an iovec.
On an all-cores multithreaded mm, the TLB shootdown broadcast takes
thousands of cycles on each core more or less regardless of how much
of the TLB gets zapped.

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

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH v2 00/13] MADV_FREE support Minchan Kim <minchan@kernel.org> - 2015-11-04 02:30 +0100
  [PATCH v2 11/13] arm: add pmd_mkclean for THP Minchan Kim <minchan@kernel.org> - 2015-11-04 02:30 +0100
  [PATCH v2 13/13] mm: don't split THP page when syscall is called Minchan Kim <minchan@kernel.org> - 2015-11-04 02:30 +0100
  [PATCH v2 04/13] mm: free swp_entry in madvise_free Minchan Kim <minchan@kernel.org> - 2015-11-04 02:30 +0100
  [PATCH v2 02/13] mm: define MADV_FREE for some arches Minchan Kim <minchan@kernel.org> - 2015-11-04 02:30 +0100
  [PATCH v2 12/13] arm64: add pmd_mkclean for THP Minchan Kim <minchan@kernel.org> - 2015-11-04 02:30 +0100
  [PATCH v2 08/13] x86: add pmd_[dirty|mkclean] for THP Minchan Kim <minchan@kernel.org> - 2015-11-04 02:30 +0100
  [PATCH v2 07/13] mm: mark stable page dirty in KSM Minchan Kim <minchan@kernel.org> - 2015-11-04 02:30 +0100
  [PATCH v2 05/13] mm: move lazily freed pages to inactive list Minchan Kim <minchan@kernel.org> - 2015-11-04 02:30 +0100
  [PATCH v2 01/13] mm: support madvise(MADV_FREE) Minchan Kim <minchan@kernel.org> - 2015-11-04 02:40 +0100
    Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE) Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2015-11-04 03:20 +0100
      Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE) Minchan Kim <minchan@kernel.org> - 2015-11-05 00:40 +0100
        Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE) Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2015-11-05 04:50 +0100
    Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE) Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2015-11-04 03:40 +0100
      Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE) Minchan Kim <minchan@kernel.org> - 2015-11-05 00:50 +0100
    Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE) Andy Lutomirski <luto@amacapital.net> - 2015-11-04 04:50 +0100
      Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE) Daniel Micay <danielmicay@gmail.com> - 2015-11-04 07:00 +0100
        Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE) Daniel Micay <danielmicay@gmail.com> - 2015-11-04 07:00 +0100
          Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE) Daniel Micay <danielmicay@gmail.com> - 2015-11-04 07:10 +0100
        Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE) Andy Lutomirski <luto@amacapital.net> - 2015-11-04 19:30 +0100
          Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE) Daniel Micay <danielmicay@gmail.com> - 2015-11-04 23:10 +0100
            Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE) Shaohua Li <shli@kernel.org> - 2015-11-05 19:20 +0100
              Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE) Daniel Micay <danielmicay@gmail.com> - 2015-11-05 21:20 +0100
                Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE) Daniel Micay <danielmicay@gmail.com> - 2015-11-05 21:20 +0100
      Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE) Minchan Kim <minchan@kernel.org> - 2015-11-05 01:20 +0100
        Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE) Andy Lutomirski <luto@amacapital.net> - 2015-11-05 01:50 +0100
          Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE) Minchan Kim <minchan@kernel.org> - 2015-11-05 02:00 +0100
            Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE) Andy Lutomirski <luto@amacapital.net> - 2015-11-05 02:40 +0100
              Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE) Minchan Kim <minchan@kernel.org> - 2015-11-05 02:50 +0100
    Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE) Shaohua Li <shli@kernel.org> - 2015-11-04 21:10 +0100
      Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE) Daniel Micay <danielmicay@gmail.com> - 2015-11-04 22:20 +0100
        Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE) Daniel Micay <danielmicay@gmail.com> - 2015-11-04 22:30 +0100
      Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE) Andy Lutomirski <luto@amacapital.net> - 2015-11-04 22:50 +0100
      Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE) Minchan Kim <minchan@kernel.org> - 2015-11-05 02:40 +0100
        Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE) Minchan Kim <minchan@kernel.org> - 2015-11-05 02:40 +0100

csiph-web