On 5.1.2019 20:24, Jiri Kosina wrote:
> On Sat, 5 Jan 2019, Vlastimil Babka wrote:
>
>>> There are possibilities [1] how mincore() could be used as a converyor of
>>> a sidechannel information about pagecache metadata.
>>>
>>> Provide vm.mincore_
On 5.1.2019 18:27, Jiri Kosina wrote:
> From: Jiri Kosina
>
> There are possibilities [1] how mincore() could be used as a converyor of
> a sidechannel information about pagecache metadata.
>
> Provide vm.mincore_privileged sysctl, which makes it possible to mincore()
> start returning -EPERM
On 1/3/19 9:42 AM, Dmitry Vyukov wrote:
> On Thu, Jan 3, 2019 at 9:36 AM Vlastimil Babka wrote:
>>
>>
>> On 12/31/18 8:51 AM, syzbot wrote:
>>> Hello,
>>>
>>> syzbot found the following crash on:
>>>
>>> HEAD commit:79fc24f
flag could have continued to be unused, there is potential
> for moving some existing fields into the flags field instead. Particularly
> read-mostly ones like zone->initialized and zone->contiguous.
>
> Reported-by: syzbot+93d94a001cfbce9e6...@syzkaller.appspotmail.com
> Tested-by:
On 1/3/19 12:14 PM, Alexander Potapenko wrote:
> On Thu, Jan 3, 2019 at 9:42 AM Dmitry Vyukov wrote:
>>
>> On Thu, Jan 3, 2019 at 9:36 AM Vlastimil Babka wrote:
>>>
>>>
>>> On 12/31/18 8:51 AM, syzbot wrote:
>>>> Hello,
>>>&g
nit access
should be benign, rebinding this kind of policy is always a no-op.
8<
>From ff0ca29da6bc2572d7b267daa77ced6083e3f02d Mon Sep 17 00:00:00 2001
From: Vlastimil Babka
Date: Thu, 3 Jan 2019 09:31:59 +0100
Subject: [PATCH] mm, mempolicy: fix uninit memory access
---
mm/mempol
On 1/2/19 9:51 AM, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:f346b0becb1b Merge branch 'akpm' (patches from Andrew)
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1510cefd40
> kernel config:
On 1/2/19 11:03 AM, Dmitry Vyukov wrote:
> On Wed, Jan 2, 2019 at 10:47 AM Vlastimil Babka wrote:
>>
>> Actually the fix was folded into the patch that caused the bug, and was
>> already sent to and merged by Linus, commit
>> 7635d9cbe8327e131a1d3d8517dc186c2796ce2e
&
On 1/2/19 10:42 AM, Dmitry Vyukov wrote:
> On Wed, Jan 2, 2019 at 8:42 AM Vlastimil Babka wrote:
>>
>> On 12/24/18 4:48 PM, syzbot wrote:
>>> Hello,
>>>
>>> syzbot found the following crash on:
>>>
>>> HEAD commit:6a1d2932
On 12/24/18 4:48 PM, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:6a1d293238c1 Add linux-next specific files for 20181224
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=149a2add40
> kernel config:
On 12/18/18 2:51 PM, Mel Gorman wrote:
> On Tue, Dec 18, 2018 at 01:36:42PM +0100, Vlastimil Babka wrote:
>> On 12/15/18 12:03 AM, Mel Gorman wrote:
>>> When pageblocks get fragmented, watermarks are artifically boosted to pages
>>> are reclaimed to avoid further fr
On 12/15/18 12:03 AM, Mel Gorman wrote:
> When pageblocks get fragmented, watermarks are artifically boosted to pages
> are reclaimed to avoid further fragmentation events. However, compaction
> is often either fragmentation-neutral or moving movable pages away from
> unmovable/reclaimable pages.
ction to use it.
>
> Signed-off-by: Mel Gorman
Acked-by: Vlastimil Babka
Nit below:
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2961,18 +2961,26 @@ void free_unref_page(struct page *page)
> /*
> * Free a list of 0-order pages
> */
> -void free_unref_pa
scanning of the pageblock is important for later patches.
>
> Signed-off-by: Mel Gorman
Acked-by: Vlastimil Babka
ts are not materially different. Scan rates are
> similar as expected.
>
> Signed-off-by: Mel Gorman
Acked-by: Vlastimil Babka
> ---
> mm/migrate.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/migrate.c b/mm/migrate.c
> index df17a710e2c7
On 12/15/18 12:03 AM, Mel Gorman wrote:
> Reserved pages are set at boot time, tend to be clustered and almost
> never become unreserved. When isolating pages for migrating, skip
> the entire pageblock is one PageReserved page is encountered on the
> grounds that it is highly probable the entire
On 12/15/18 12:03 AM, Mel Gorman wrote:
> It's non-obvious that high-order free pages are split into order-0
> pages from the function name. Fix it.
That's fine, but looks like the patch has another change squashed into
it that removes zone parameter from several functions and uses cc->zone
frequent drains.
> Signed-off-by: Mel Gorman
Acked-by: Vlastimil Babka
ing exercise than anything.
>
> Signed-off-by: Mel Gorman
Acked-by: Vlastimil Babka
On 12/15/18 12:02 AM, Mel Gorman wrote:
> The isolate and migrate scanners should never isolate more than a pageblock
> of pages so unsigned int is sufficient saving 8 bytes on a 64-bit build.
>
> Signed-off-by: Mel Gorman
Acked-by: Vlastimil Babka
> ---
> mm/internal.h
On 12/14/18 10:04 PM, David Rientjes wrote:
> On Wed, 12 Dec 2018, Vlastimil Babka wrote:
...
> Reclaim likely could be deterministically useful if we consider a redesign
> of how migration sources and targets are determined in compaction.
>
> Has anybody tried a migration sca
injected. On the other hand, this patch adds an
unconditional call to should_fail_alloc_page() from page allocation
hotpath. That overhead should be rather negligible with
CONFIG_FAIL_PAGE_ALLOC=n when there's no kprobe attached, though.
> Signed-off-by: Benjamin Poirier
Acked-by: Vla
On 12/13/18 8:38 PM, Waiman Long wrote:
> Using down_read_trylock() to check if a task holds a write lock on
> a rwsem is not reliable. A task can hold a read lock on a rwsem and
> down_read_trylock() can fail if a writer is waiting in the wait queue.
>
> So use lockdep_assert_held_exclusive()
On 12/12/18 1:37 AM, David Rientjes wrote:
>
> Regarding the role of direct reclaim in the allocator, I think we need
> work on the feedback from compaction to determine whether it's worthwhile.
> That's difficult because of the point I continue to bring up:
> isolate_freepages() is not
On 12/7/18 11:50 PM, David Rientjes wrote:
> This reverts commit 89c83fb539f95491be80cdd5158e6f0ce329e317.
>
> This should have been done as part of 2f0799a0ffc0 ("mm, thp: restore
> node-local hugepage allocations"). The movement of the thp allocation
> policy from alloc_pages_vma() to
On 12/7/18 11:50 PM, David Rientjes wrote:
> This reverts commit 89c83fb539f95491be80cdd5158e6f0ce329e317.
>
> This should have been done as part of 2f0799a0ffc0 ("mm, thp: restore
> node-local hugepage allocations"). The movement of the thp allocation
> policy from alloc_pages_vma() to
On 12/7/18 7:16 AM, Nicolas Boichat wrote:
> IOMMUs using ARMv7 short-descriptor format require page tables
> (level 1 and 2) to be allocated within the first 4GB of RAM, even
> on 64-bit systems.
>
> For level 1/2 pages, ensure GFP_DMA32 is used if CONFIG_ZONE_DMA32
> is defined (e.g. on arm64
On 12/6/18 11:00 PM, David Rientjes wrote:
> This reverts commit 89c83fb539f95491be80cdd5158e6f0ce329e317.
>
> There are a couple of issues with 89c83fb539f9 independent of its partial
> revert in 2f0799a0ffc0 ("mm, thp: restore node-local hugepage
> allocations"):
>
> Firstly, the interaction
On 12/6/18 11:00 PM, David Rientjes wrote:
> This reverts commit 89c83fb539f95491be80cdd5158e6f0ce329e317.
>
> There are a couple of issues with 89c83fb539f9 independent of its partial
> revert in 2f0799a0ffc0 ("mm, thp: restore node-local hugepage
> allocations"):
>
> Firstly, the interaction
On 12/7/18 8:49 AM, Michal Hocko wrote:
>> But *that* in turn makes for other possible questions:
>>
>> - if the reason we couldn't get a local hugepage is that we're simply
>> out of local memory (huge *or* small), then maybe a remote hugepage is
>> better.
>>
>>Note that this now implies
On 12/7/18 8:49 AM, Michal Hocko wrote:
>> But *that* in turn makes for other possible questions:
>>
>> - if the reason we couldn't get a local hugepage is that we're simply
>> out of local memory (huge *or* small), then maybe a remote hugepage is
>> better.
>>
>>Note that this now implies
2
> kmem_cache must _not_ use GFP_DMA32 (it is anyway redundant and
> unnecessary).
>
> Signed-off-by: Nicolas Boichat
Acked-by: Vlastimil Babka
On 12/6/18 1:54 AM, Andrea Arcangeli wrote:
> On Wed, Dec 05, 2018 at 04:18:14PM -0800, David Rientjes wrote:
>> On Wed, 5 Dec 2018, Andrea Arcangeli wrote:
>>
>> Note that in addition to COMPACT_SKIPPED that you mention, compaction can
>> fail with COMPACT_COMPLETE, meaning the full scan has
On 12/6/18 1:54 AM, Andrea Arcangeli wrote:
> On Wed, Dec 05, 2018 at 04:18:14PM -0800, David Rientjes wrote:
>> On Wed, 5 Dec 2018, Andrea Arcangeli wrote:
>>
>> Note that in addition to COMPACT_SKIPPED that you mention, compaction can
>> fail with COMPACT_COMPLETE, meaning the full scan has
On 12/5/18 10:29 AM, Pingfan Liu wrote:
>> [0.007418] Early memory node ranges
>> [0.007419] node 1: [mem 0x1000-0x0008efff]
>> [0.007420] node 1: [mem 0x0009-0x0009]
>> [0.007422] node 1: [mem
On 12/5/18 10:29 AM, Pingfan Liu wrote:
>> [0.007418] Early memory node ranges
>> [0.007419] node 1: [mem 0x1000-0x0008efff]
>> [0.007420] node 1: [mem 0x0009-0x0009]
>> [0.007422] node 1: [mem
On 12/4/18 9:56 AM, Michal Hocko wrote:
>> The device's node num is 2. And in my case, I used nr_cpus param. Due
>> to init_cpu_to_node() initialize all the possible node. It is hard
>> for me to figure out without this param, how zonelists is accessed
>> before page allocator works.
> I believe
On 12/4/18 9:56 AM, Michal Hocko wrote:
>> The device's node num is 2. And in my case, I used nr_cpus param. Due
>> to init_cpu_to_node() initialize all the possible node. It is hard
>> for me to figure out without this param, how zonelists is accessed
>> before page allocator works.
> I believe
On 12/4/18 12:50 AM, David Rientjes wrote:
> This fixes a 13.9% of remote memory access regression and 40% remote
> memory allocation regression on Haswell when the local node is fragmented
> for hugepage sized pages and memory is being faulted with either the thp
> defrag setting of "always" or
On 12/4/18 12:50 AM, David Rientjes wrote:
> This fixes a 13.9% of remote memory access regression and 40% remote
> memory allocation regression on Haswell when the local node is fragmented
> for hugepage sized pages and memory is being faulted with either the thp
> defrag setting of "always" or
On 12/3/18 11:27 PM, Linus Torvalds wrote:
> On Mon, Dec 3, 2018 at 2:04 PM Linus Torvalds
> wrote:
>>
>> so I think all of David's patch is somewhat sensible, even if that
>> specific "order == pageblock_order" test really looks like it might
>> want to be clarified.
>
> Side note: I think
On 12/3/18 11:27 PM, Linus Torvalds wrote:
> On Mon, Dec 3, 2018 at 2:04 PM Linus Torvalds
> wrote:
>>
>> so I think all of David's patch is somewhat sensible, even if that
>> specific "order == pageblock_order" test really looks like it might
>> want to be clarified.
>
> Side note: I think
On 11/29/18 1:52 PM, Greg KH wrote:
> On Tue, Oct 30, 2018 at 05:48:25PM +, Roman Gushchin wrote:
>> BTW, in 4.19+ the counter has been renamed and exported by
>> the commit b29940c1abd7 ("mm: rename and change semantics of
>> nr_indirectly_reclaimable_bytes"), so there is no such a problem
>>
On 11/29/18 1:52 PM, Greg KH wrote:
> On Tue, Oct 30, 2018 at 05:48:25PM +, Roman Gushchin wrote:
>> BTW, in 4.19+ the counter has been renamed and exported by
>> the commit b29940c1abd7 ("mm: rename and change semantics of
>> nr_indirectly_reclaimable_bytes"), so there is no such a problem
>>
On 11/27/18 8:05 PM, Vlastimil Babka wrote:
> On 11/27/18 6:08 PM, Linus Torvalds wrote:
>> On Mon, Nov 26, 2018 at 10:24 PM kernel test robot
>> wrote:
>>>
>>> FYI, we noticed a -61.3% regression of vm-scalability.throughput due
>>> to commit ac
On 11/27/18 8:05 PM, Vlastimil Babka wrote:
> On 11/27/18 6:08 PM, Linus Torvalds wrote:
>> On Mon, Nov 26, 2018 at 10:24 PM kernel test robot
>> wrote:
>>>
>>> FYI, we noticed a -61.3% regression of vm-scalability.throughput due
>>> to commit ac
On 11/27/18 6:08 PM, Linus Torvalds wrote:
> On Mon, Nov 26, 2018 at 10:24 PM kernel test robot
> wrote:
>>
>> FYI, we noticed a -61.3% regression of vm-scalability.throughput due
>> to commit ac5b2c18911f ("mm: thp: relax __GFP_THISNODE for
>> MADV_HUGEPAGE mappings")
>
> Well, that's certainly
On 11/27/18 6:08 PM, Linus Torvalds wrote:
> On Mon, Nov 26, 2018 at 10:24 PM kernel test robot
> wrote:
>>
>> FYI, we noticed a -61.3% regression of vm-scalability.throughput due
>> to commit ac5b2c18911f ("mm: thp: relax __GFP_THISNODE for
>> MADV_HUGEPAGE mappings")
>
> Well, that's certainly
On 11/27/18 3:50 PM, William Kucharski wrote:
>
> I was just double checking that this was meant to be more of a check done
> before code elsewhere performs additional checks and does the actual THP
> mapping, not an all-encompassing go/no go check for THP mapping.
Yes, the code doing the actual
On 11/27/18 3:50 PM, William Kucharski wrote:
>
> I was just double checking that this was meant to be more of a check done
> before code elsewhere performs additional checks and does the actual THP
> mapping, not an all-encompassing go/no go check for THP mapping.
Yes, the code doing the actual
On 11/23/18 12:45 PM, Mel Gorman wrote:
> An event that potentially causes external fragmentation problems has
> already been described but there are degrees of severity. A "serious"
> event is defined as one that steals a contiguous range of pages of an order
> lower than fragment_stall_order
On 11/23/18 12:45 PM, Mel Gorman wrote:
> An event that potentially causes external fragmentation problems has
> already been described but there are degrees of severity. A "serious"
> event is defined as one that steals a contiguous range of pages of an order
> lower than fragment_stall_order
87.98 ( -7.53%)
>
> There is a large reduction in fragmentation events with some jitter around
> the latencies and success rates. As before, the high THP allocation
> success rate does mean the system is under a lot of pressure. However,
> as the fragmentation events are reduced, it would be expected that the
> long-term allocation success rate would be higher.
>
> Signed-off-by: Mel Gorman
Acked-by: Vlastimil Babka
87.98 ( -7.53%)
>
> There is a large reduction in fragmentation events with some jitter around
> the latencies and success rates. As before, the high THP allocation
> success rate does mean the system is under a lot of pressure. However,
> as the fragmentation events are reduced, it would be expected that the
> long-term allocation success rate would be higher.
>
> Signed-off-by: Mel Gorman
Acked-by: Vlastimil Babka
w treat a PageWaiters page as if an extra
> reference were held? Perhaps, but I don't think it matters much, since
> shrink_page_list() already had to win its trylock_page(), so waiters are
> not very common there: I noticed no difference when trying the bigger
> change, and it's surely not needed while put_and_wait_on_page_locked()
> is only used for page migration.
>
> Reported-and-tested-by: Baoquan He
> Signed-off-by: Hugh Dickins
> Acked-by: Michal Hocko
> Reviewed-by: Andrea Arcangeli
Acked-by: Vlastimil Babka
Thanks!
w treat a PageWaiters page as if an extra
> reference were held? Perhaps, but I don't think it matters much, since
> shrink_page_list() already had to win its trylock_page(), so waiters are
> not very common there: I noticed no difference when trying the bigger
> change, and it's surely not needed while put_and_wait_on_page_locked()
> is only used for page migration.
>
> Reported-and-tested-by: Baoquan He
> Signed-off-by: Hugh Dickins
> Acked-by: Michal Hocko
> Reviewed-by: Andrea Arcangeli
Acked-by: Vlastimil Babka
Thanks!
>
> Signed-off-by: Mel Gorman
Acked-by: Vlastimil Babka
Small bug below:
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3278,10 +3278,15 @@ static bool zone_allows_reclaim(struct zone
> *local_zone, struct zone *zone)
> * fragmentation between the Normal an
>
> Signed-off-by: Mel Gorman
Acked-by: Vlastimil Babka
Small bug below:
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3278,10 +3278,15 @@ static bool zone_allows_reclaim(struct zone
> *local_zone, struct zone *zone)
> * fragmentation between the Normal an
ragmentation causing
> events so the success of THP over long periods of time would be improved
> for this adverse workload.
>
> Signed-off-by: Mel Gorman
Acked-by: Vlastimil Babka
ragmentation causing
> events so the success of THP over long periods of time would be improved
> for this adverse workload.
>
> Signed-off-by: Mel Gorman
Acked-by: Vlastimil Babka
On 11/26/18 3:01 AM, Matthew Wilcox wrote:
> On Mon, Nov 26, 2018 at 07:58:23AM +0800, Yang Yang wrote:
>> When si_mem_available() calculates 'available', it takes SWAP
>> into account. But if CONFIG_SWAP is N or SWAP is off(some embedded system
>> would like to do that), there is no need to
On 11/26/18 3:01 AM, Matthew Wilcox wrote:
> On Mon, Nov 26, 2018 at 07:58:23AM +0800, Yang Yang wrote:
>> When si_mem_available() calculates 'available', it takes SWAP
>> into account. But if CONFIG_SWAP is N or SWAP is off(some embedded system
>> would like to do that), there is no need to
; already export that information via sysfs
>
> Fixes: 1860033237d4 ("mm: make PR_SET_THP_DISABLE immediately active")
> Signed-off-by: Michal Hocko
Acked-by: Vlastimil Babka
; already export that information via sysfs
>
> Fixes: 1860033237d4 ("mm: make PR_SET_THP_DISABLE immediately active")
> Signed-off-by: Michal Hocko
Acked-by: Vlastimil Babka
On 11/23/18 4:21 PM, Michal Hocko wrote:
> On Fri 23-11-18 16:07:06, Vlastimil Babka wrote:
>> On 11/20/18 11:35 AM, Michal Hocko wrote:
>>> From: Michal Hocko
>>>
>>> Userspace falls short when trying to find out whether a specific memory
>>>
On 11/23/18 4:21 PM, Michal Hocko wrote:
> On Fri 23-11-18 16:07:06, Vlastimil Babka wrote:
>> On 11/20/18 11:35 AM, Michal Hocko wrote:
>>> From: Michal Hocko
>>>
>>> Userspace falls short when trying to find out whether a specific memory
>>>
ays better suited to report this,
than userspace piecing it together from multiple sources, relying on
possibly outdated knowledge of kernel implementation details...
Acked-by: Vlastimil Babka
A nitpick:
> ---
> Documentation/filesystems/proc.txt | 3 +++
> fs/proc/task_mmu.c
ays better suited to report this,
than userspace piecing it together from multiple sources, relying on
possibly outdated knowledge of kernel implementation details...
Acked-by: Vlastimil Babka
A nitpick:
> ---
> Documentation/filesystems/proc.txt | 3 +++
> fs/proc/task_mmu.c
e. While this has been worked on and it will be fixed properly,
> it seems that our wording could see some refinement and be more vocal
> about semantic aspect of these flags as well.
>
> Cc: Jan Kara
> Cc: Dan Williams
> Cc: David Rientjes
> Signed-off-by
e. While this has been worked on and it will be fixed properly,
> it seems that our wording could see some refinement and be more vocal
> about semantic aspect of these flags as well.
>
> Cc: Jan Kara
> Cc: Dan Williams
> Cc: David Rientjes
> Signed-off-by
On 11/21/18 11:14 AM, Mel Gorman wrote:
> An event that potentially causes external fragmentation problems has
> already been described but there are degrees of severity. A "serious"
> event is defined as one that steals a contiguous range of pages of an order
> lower than fragment_stall_order
On 11/21/18 11:14 AM, Mel Gorman wrote:
> An event that potentially causes external fragmentation problems has
> already been described but there are degrees of severity. A "serious"
> event is defined as one that steals a contiguous range of pages of an order
> lower than fragment_stall_order
On 11/22/18 4:04 PM, Mel Gorman wrote:
> On Thu, Nov 22, 2018 at 02:53:08PM +0100, Vlastimil Babka wrote:
>>
>> So the reason I was wondering about movable vs unmovable fallbacks here
>> is that movable fallbacks are ok as they can be migrated later, but the
>> unmov
On 11/22/18 4:04 PM, Mel Gorman wrote:
> On Thu, Nov 22, 2018 at 02:53:08PM +0100, Vlastimil Babka wrote:
>>
>> So the reason I was wondering about movable vs unmovable fallbacks here
>> is that movable fallbacks are ok as they can be migrated later, but the
>> unmov
On 11/21/18 11:14 AM, Mel Gorman wrote:
> An external fragmentation event was previously described as
>
> When the page allocator fragments memory, it records the event using
> the mm_page_alloc_extfrag event. If the fallback_order is smaller
> than a pageblock order (order-9 on
On 11/21/18 11:14 AM, Mel Gorman wrote:
> An external fragmentation event was previously described as
>
> When the page allocator fragments memory, it records the event using
> the mm_page_alloc_extfrag event. If the fallback_order is smaller
> than a pageblock order (order-9 on
On 11/21/18 11:14 AM, Mel Gorman wrote:
> This is a preparation patch only, no functional change.
>
> Signed-off-by: Mel Gorman
Acked-by: Vlastimil Babka
On 11/21/18 11:14 AM, Mel Gorman wrote:
> This is a preparation patch only, no functional change.
>
> Signed-off-by: Mel Gorman
Acked-by: Vlastimil Babka
On 11/21/18 11:14 AM, Mel Gorman wrote:
> The page allocator zone lists are iterated based on the watermarks
> of each zone which does not take anti-fragmentation into account. On
> x86, node 0 may have multiple zones while other nodes have one zone. A
> consequence is that tasks running on node 0
On 11/21/18 11:14 AM, Mel Gorman wrote:
> The page allocator zone lists are iterated based on the watermarks
> of each zone which does not take anti-fragmentation into account. On
> x86, node 0 may have multiple zones while other nodes have one zone. A
> consequence is that tasks running on node 0
On 11/13/18 7:22 PM, Vlastimil Babka wrote:
> On 11/12/18 10:55 AM, David Laight wrote:
>> From: Vlastimil Babka [mailto:vba...@suse.cz]
>>> Sent: 09 November 2018 19:16
>> ...
>>> This? Not terribly elegant, but I don't see a nicer way right now...
>>
>&g
On 11/13/18 7:22 PM, Vlastimil Babka wrote:
> On 11/12/18 10:55 AM, David Laight wrote:
>> From: Vlastimil Babka [mailto:vba...@suse.cz]
>>> Sent: 09 November 2018 19:16
>> ...
>>> This? Not terribly elegant, but I don't see a nicer way right now...
>>
>&g
On 11/20/18 6:44 AM, Hugh Dickins wrote:
> [PATCH] mm: put_and_wait_on_page_locked() while page is migrated
>
> We have all assumed that it is essential to hold a page reference while
> waiting on a page lock: partly to guarantee that there is still a struct
> page when MEMORY_HOTREMOVE is
On 11/20/18 6:44 AM, Hugh Dickins wrote:
> [PATCH] mm: put_and_wait_on_page_locked() while page is migrated
>
> We have all assumed that it is essential to hold a page reference while
> waiting on a page lock: partly to guarantee that there is still a struct
> page when MEMORY_HOTREMOVE is
On 11/19/18 5:46 PM, Vlastimil Babka wrote:
> On 11/19/18 5:46 PM, Michal Hocko wrote:
>> On Mon 19-11-18 17:36:21, Vlastimil Babka wrote:
>>>
>>> So what protects us from locking a page whose refcount dropped to zero?
>>> and is being freed? The checks
On 11/19/18 5:46 PM, Vlastimil Babka wrote:
> On 11/19/18 5:46 PM, Michal Hocko wrote:
>> On Mon 19-11-18 17:36:21, Vlastimil Babka wrote:
>>>
>>> So what protects us from locking a page whose refcount dropped to zero?
>>> and is being freed? The checks
On 11/19/18 5:46 PM, Michal Hocko wrote:
> On Mon 19-11-18 17:36:21, Vlastimil Babka wrote:
>>
>> So what protects us from locking a page whose refcount dropped to zero?
>> and is being freed? The checks in freeing path won't be happy about a
>> stray lock.
&
On 11/19/18 5:46 PM, Michal Hocko wrote:
> On Mon 19-11-18 17:36:21, Vlastimil Babka wrote:
>>
>> So what protects us from locking a page whose refcount dropped to zero?
>> and is being freed? The checks in freeing path won't be happy about a
>> stray lock.
&
On 11/19/18 3:10 PM, Michal Hocko wrote:
> On Mon 19-11-18 13:51:21, Michal Hocko wrote:
>> On Mon 19-11-18 13:40:33, Michal Hocko wrote:
>>> How are
>>> we supposed to converge when the swapin code waits for the migration to
>>> finish with the reference count elevated?
Indeed this looks wrong.
On 11/19/18 3:10 PM, Michal Hocko wrote:
> On Mon 19-11-18 13:51:21, Michal Hocko wrote:
>> On Mon 19-11-18 13:40:33, Michal Hocko wrote:
>>> How are
>>> we supposed to converge when the swapin code waits for the migration to
>>> finish with the reference count elevated?
Indeed this looks wrong.
slub: introduce kmalloc-reclaimable caches")
>> Cc: Vlastimil Babka
>> Cc: Mel Gorman
>> Cc: Christoph Lameter
>> Cc: Roman Gushchin
>> Signed-off-by: Bart Van Assche
>> ---
>> include/linux/slab.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 d
slub: introduce kmalloc-reclaimable caches")
>> Cc: Vlastimil Babka
>> Cc: Mel Gorman
>> Cc: Christoph Lameter
>> Cc: Roman Gushchin
>> Signed-off-by: Bart Van Assche
>> ---
>> include/linux/slab.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 d
On 11/14/18 12:32 AM, Andrew Morton wrote:
> On Wed, 14 Nov 2018 00:23:28 +0100 Vlastimil Babka wrote:
>
>> On 11/14/18 12:15 AM, Andrew Morton wrote:
>>> On Tue, 13 Nov 2018 10:43:05 +0100 Michal Hocko wrote:
>>>
>>>> --- a/mm/page_alloc.c
>>&
On 11/14/18 12:32 AM, Andrew Morton wrote:
> On Wed, 14 Nov 2018 00:23:28 +0100 Vlastimil Babka wrote:
>
>> On 11/14/18 12:15 AM, Andrew Morton wrote:
>>> On Tue, 13 Nov 2018 10:43:05 +0100 Michal Hocko wrote:
>>>
>>>> --- a/mm/page_alloc.c
>>&
On 11/14/18 12:15 AM, Andrew Morton wrote:
> On Tue, 13 Nov 2018 10:43:05 +0100 Michal Hocko wrote:
>
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -4364,6 +4353,15 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int
>> order, int preferred_nid,
>> gfp_t alloc_mask; /* The
On 11/14/18 12:15 AM, Andrew Morton wrote:
> On Tue, 13 Nov 2018 10:43:05 +0100 Michal Hocko wrote:
>
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -4364,6 +4353,15 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int
>> order, int preferred_nid,
>> gfp_t alloc_mask; /* The
On 11/12/18 10:55 AM, David Laight wrote:
> From: Vlastimil Babka [mailto:vba...@suse.cz]
>> Sent: 09 November 2018 19:16
> ...
>> This? Not terribly elegant, but I don't see a nicer way right now...
>
> Maybe just have two copies of the function body?
>
>
On 11/12/18 10:55 AM, David Laight wrote:
> From: Vlastimil Babka [mailto:vba...@suse.cz]
>> Sent: 09 November 2018 19:16
> ...
>> This? Not terribly elegant, but I don't see a nicer way right now...
>
> Maybe just have two copies of the function body?
>
>
On 11/10/18 8:20 PM, Greg KH wrote:
> On Sat, Nov 10, 2018 at 10:52:06AM -0800, Daniel Colascione wrote:
>> Now that glibc is basically not adding any new system call wrappers,
>
> Why are they not doing that anymore?
FYI just noticed there's a topic relevant to this in LPC Toolchain MC:
On 11/10/18 8:20 PM, Greg KH wrote:
> On Sat, Nov 10, 2018 at 10:52:06AM -0800, Daniel Colascione wrote:
>> Now that glibc is basically not adding any new system call wrappers,
>
> Why are they not doing that anymore?
FYI just noticed there's a topic relevant to this in LPC Toolchain MC:
901 - 1000 of 6104 matches
Mail list logo
