gt; I think it should actually be fine to remove z3fold without deprecating
> it first, but I am doing the due diligence.
Yeah, you never know for sure if users exist. Deprecating it for a few
cycles is the safer option.
Acked-by: Johannes Weiner
ric fault to be accounted, unlike VM_FAULT_RETRY.
>
> I explicitly didn't touch hmm_vma_fault() and break_ksm() because they do
> not handle VM_FAULT_RETRY even with existing code, so I'm literally keeping
> them as-is.
>
> Signed-off-by: Peter Xu
Acked-by: Johannes Weiner
On Tue, Oct 20, 2020 at 05:52:07PM +0200, Vlastimil Babka wrote:
> On 10/8/20 11:49 AM, Christophe Leroy wrote:
> > In a 10 years old commit
> > (https://github.com/linuxppc/linux/commit/d069cb4373fe0d451357c4d3769623a7564dfa9f),
> > powerpc 8xx has
> > made the handling of PTE accessed bit condit
atch in linux-next up tuntil today
> is different. :-(
Sorry, I made a last-minute request to include these checks in that
patch to make the code a bit more robust, but they trigger a false
positive here. Let's remove them.
---
>From de8ea7c96c056c3cbe7b93995029986a158fb9cd Mon Sep 17 00:00
>
> The renaming is done by using the command sequence:
>
> git grep -w --name-only kzfree |\
> xargs sed -i 's/\bkzfree\b/kfree_sensitive/'
>
> followed by some editing of the kfree_sensitive() kerneldoc and the
> use of memzero_explicit() instead of memset().
>
> Suggested-by: Joe Perches
> Signed-off-by: Waiman Long
Looks good to me. Thanks for fixing this very old mistake.
Acked-by: Johannes Weiner
t; For this to compile for the nommu case add a __vmalloc_node_range stub
> > to nommu.c.
> >
> > Signed-off-by: Christoph Hellwig
Acked-by: Johannes Weiner
istoph Lameter
> Cc: Pekka Enberg
> Cc: Joonsoo Kim
> Cc: Naoya Horiguchi
> Cc: Tony Luck
> Cc: Fenghua Yu
> Cc: Arnd Bergmann
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Acked-by: Michael Ellerman
> Cc: Gleb Natapov
> Cc: Paolo Bonzini
&g
xisting buggy callers, change the VM_BUG_ON
> in __alloc_pages_node() to VM_WARN_ON.
>
> Signed-off-by: Vlastimil Babka
> Acked-by: David Rientjes
Acked-by: Johannes Weiner
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Thu, Jul 30, 2015 at 06:34:31PM +0200, Vlastimil Babka wrote:
> numa_mem_id() is able to handle allocation from CPUs on memory-less nodes,
> so it's a more robust fallback than the currently used numa_node_id().
Won't it fall through to the next closest memory node in the zonelist
anyway? Is th
On Fri, Jun 15, 2012 at 09:19:45PM +0800, Wanpeng Li wrote:
> From: Wanpeng Li
>
> Since there are five lists in LRU cache, the array nr in get_scan_count
> should be:
>
> nr[0] = anon inactive pages to scan; nr[1] = anon active pages to scan
> nr[2] = file inactive pages to scan; nr[3] = file a
64f10 .sparse_init+0x12c/0x28c
> [c0c03e20] c0a474f4 .setup_arch+0x20c/0x294
> [c0c03ee0] c0a4079c .start_kernel+0xb4/0x460
> [c0c03f90] c0009670 .start_here_common+0x1c/0x2c
>
> This is
>
> BUG_ON(limit && goal + s
On Tue, Feb 28, 2012 at 12:11:51PM -0800, Nishanth Aravamudan wrote:
> On 28.02.2012 [14:53:26 +0100], Johannes Weiner wrote:
> > On Fri, Feb 24, 2012 at 11:33:58AM -0800, Nishanth Aravamudan wrote:
> > > While testing AMS (Active Memory Sharing) / CMO (Cooperative Memory
&g
since we actually have HOTREMOVE
> defined, we'll BUG_ON() instead. A simple solution appears to be to
> disable the limit check if the size of the allocation in
> alloc_bootmem_secition exceeds the section size.
It makes sense to allow the usemaps to spill over to subsequent
sections
13 matches
Mail list logo
