struct virtio_device *vdev;
> struct virtqueue *inflate_vq, *deflate_vq, *stats_vq;
>
> --
> MST
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to maj
On Thu 15-01-15 15:44:12, Michael S. Tsirkin wrote:
> On Thu, Jan 15, 2015 at 02:06:42PM +0100, Michal Hocko wrote:
> > On Thu 15-01-15 13:39:06, Michael S. Tsirkin wrote:
> > > Most of our code has
> > > struct foo {
> > > }
> > >
> > > Fix t
On Thu 15-01-15 20:50:18, Michael S. Tsirkin wrote:
> On Thu, Jan 15, 2015 at 03:13:08PM +0100, Michal Hocko wrote:
> > On Thu 15-01-15 15:44:12, Michael S. Tsirkin wrote:
[...]
> > > Maybe send patch dropping include/uapi/ from there,
> > > should help drive the volume
ll the poison value at a single place to make them obviously
unique.
> Signed-off-by: Wei Wang
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: Michael S. Tsirkin
> ---
> include/linux/poison.h | 7 ---
> mm/page_poison.c | 6 ++
> 2 files changed, 6 inse
context.
> > > + *
> > > + * There is no guarantee that each free range will be reported only once
> > > + * during one walk_free_mem_block invocation.
> > > + *
> > > + * pfn_to_page on the given range is strongly discouraged and if there is
> > &
On Tue 27-03-18 19:07:22, Michael S. Tsirkin wrote:
> On Tue, Mar 27, 2018 at 08:33:22AM +0200, Michal Hocko wrote:
> > > > > + * The function itself might sleep so it cannot be called from atomic
> > > > > + * contexts.
> > > > I don't see how wa
CONFIG_DEBUG_VM tends to be
enabled quite often.
> Signed-off-by: Mikulas Patocka
Nacked-by: Michal Hocko
> ---
> mm/util.c |2 ++
> 1 file changed, 2 insertions(+)
>
> Index: linux-2.6/mm/util.c
> ===
> --- l
On Fri 20-04-18 06:41:36, Matthew Wilcox wrote:
> On Fri, Apr 20, 2018 at 03:08:52PM +0200, Michal Hocko wrote:
> > > In order to detect these bugs reliably I submit this patch that changes
> > > kvmalloc to always use vmalloc if CONFIG_DEBUG_VM is turned on.
> >
>
On Sat 21-04-18 07:47:57, Matthew Wilcox wrote:
> On Fri, Apr 20, 2018 at 05:21:26PM -0400, Mikulas Patocka wrote:
> > On Fri, 20 Apr 2018, Matthew Wilcox wrote:
> > > On Fri, Apr 20, 2018 at 04:54:53PM -0400, Mikulas Patocka wrote:
> > > > On Fri, 20 Apr 2018, Michal
>
> The testing people won't set it up. They install the "kernel-debug"
> package and run the tests in it.
>
> If you introduce a hidden option that no one knows about, no one will use
> it.
then make sure people know about it. Fuzzers already do test fault
in
04:54:53PM -0400, Mikulas Patocka wrote:
> > > > > On Fri, 20 Apr 2018, Michal Hocko wrote:
> > > > > > No way. This is just wrong! First of all, you will explode most
> > > > > > likely
> > > > > > on many allocations of small sizes. S
; +#ifdef CONFIG_DEBUG_SG
> +do_vmalloc:
> +#endif
> return __vmalloc_node_flags_caller(size, node, flags,
> __builtin_return_address(0));
> }
--
Michal Hocko
SUSE Labs
___
Virtualization mailing list
Vir
On Mon 23-04-18 20:25:15, Mikulas Patocka wrote:
>
>
> On Mon, 23 Apr 2018, Michal Hocko wrote:
>
> > On Mon 23-04-18 10:06:08, Mikulas Patocka wrote:
> >
> > > > > He didn't want to fix vmalloc(GFP_NOIO)
> > > >
> > > > I do
On Tue 24-04-18 11:30:40, Mikulas Patocka wrote:
>
>
> On Tue, 24 Apr 2018, Michal Hocko wrote:
>
> > On Mon 23-04-18 20:25:15, Mikulas Patocka wrote:
> >
> > > Fixing __vmalloc code
> > > is easy and it doesn't require cooperation with mai
On Tue 24-04-18 11:50:30, Mikulas Patocka wrote:
>
>
> On Tue, 24 Apr 2018, Michal Hocko wrote:
>
> > On Mon 23-04-18 20:06:16, Mikulas Patocka wrote:
> > [...]
> > > @@ -404,6 +405,12 @@ void *kvmalloc_node(size_t size, gfp_t f
> > >*
On Tue 24-04-18 10:12:42, Michal Hocko wrote:
> On Tue 24-04-18 11:30:40, Mikulas Patocka wrote:
> >
> >
> > On Tue, 24 Apr 2018, Michal Hocko wrote:
> >
> > > On Mon 23-04-18 20:25:15, Mikulas Patocka wrote:
> > >
> > > > Fixi
On Tue 24-04-18 13:00:11, Mikulas Patocka wrote:
>
>
> On Tue, 24 Apr 2018, Michal Hocko wrote:
>
> > On Tue 24-04-18 11:50:30, Mikulas Patocka wrote:
> > >
> > >
> > > On Tue, 24 Apr 2018, Michal Hocko wrote:
> > >
&
On Tue 24-04-18 13:28:49, Mikulas Patocka wrote:
>
>
> On Tue, 24 Apr 2018, Michal Hocko wrote:
>
> > On Tue 24-04-18 13:00:11, Mikulas Patocka wrote:
> > >
> > >
> > > On Tue, 24 Apr 2018, Michal Hocko wrote:
> > >
&
;t provided any argument that would
explain why the kernel package cannot add a boot option. Maybe there are
some but I do not see them right now.
--
Michal Hocko
SUSE Labs
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
r, so there is a
risk of harm IIUC and this is not much different than other fault
injecting paths.
--
Michal Hocko
SUSE Labs
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
r ballooning that way. And if you still feel you have tons
> of free memory, just continue removing more pages from the free list.
We already have an interface for that. alloc_pages(GFP_NOWAIT, MAX_ORDER -1).
So why do we need any array based interface?
--
Michal
On Wed 11-07-18 18:52:45, Wei Wang wrote:
> On 07/11/2018 05:21 PM, Michal Hocko wrote:
> > On Tue 10-07-18 18:44:34, Linus Torvalds wrote:
> > [...]
> > > That was what I tried to encourage with actually removing the pages
> > > form the page list. That would b
On Wed 11-07-18 13:55:15, Wang, Wei W wrote:
> On Wednesday, July 11, 2018 7:10 PM, Michal Hocko wrote:
> > On Wed 11-07-18 18:52:45, Wei Wang wrote:
> > > On 07/11/2018 05:21 PM, Michal Hocko wrote:
> > > > On Tue 10-07-18 18:44:34, Linus Torvalds wrote:
> >
go away sooner or later (I would much rather like the former) so
do not build a new logic on top of it. I would appreciate if you
actually remove the notifier much more.
You can give memory back from the standard shrinker interface. If we are
On Thu 12-07-18 19:34:16, Wei Wang wrote:
> On 07/12/2018 04:13 PM, Michal Hocko wrote:
> > On Thu 12-07-18 10:52:08, Wei Wang wrote:
> > > On 07/12/2018 10:30 AM, Linus Torvalds wrote:
> > > > On Wed, Jul 11, 2018 at 7:17 PM Wei Wang wrote:
> > > > >
over design this thing from the early beginning.
[1] http://lkml.kernel.org/r/20170109163518.6001-5-mgor...@techsingularity.net
--
Michal Hocko
SUSE Labs
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux
On Fri 27-07-18 17:24:55, Wei Wang wrote:
> The OOM notifier is getting deprecated to use for the reasons mentioned
> here by Michal Hocko: https://lkml.org/lkml/2018/7/12/314
>
> This patch replaces the virtio-balloon oom notifier with a shrinker
> to release balloon pages on
On Wed 01-08-18 19:12:25, Wei Wang wrote:
> On 07/30/2018 05:00 PM, Michal Hocko wrote:
> > On Fri 27-07-18 17:24:55, Wei Wang wrote:
> > > The OOM notifier is getting deprecated to use for the reasons mentioned
> > > here by Michal Hocko: https://lkml.org/lkml/2018
On Thu 02-08-18 19:27:40, Wei Wang wrote:
> On 08/02/2018 07:00 PM, Tetsuo Handa wrote:
> > On 2018/08/02 19:32, Wei Wang wrote:
> > > On 08/01/2018 07:34 PM, Michal Hocko wrote:
> > > > Do you have any numbers for how does this work in practice?
> > > It wor
On Thu 02-08-18 18:32:44, Wei Wang wrote:
> On 08/01/2018 07:34 PM, Michal Hocko wrote:
> > On Wed 01-08-18 19:12:25, Wei Wang wrote:
> > > On 07/30/2018 05:00 PM, Michal Hocko wrote:
> > > > On Fri 27-07-18 17:24:55, Wei Wang wrote:
> > > > > The OOM
From: Michal Hocko
b92b1b89a33c ("virtio: force vring descriptors to be allocated from
lowmem") tried to exclude highmem pages for descriptors so it cleared
__GFP_HIGHMEM from a given gfp mask. The patch also cleared __GFP_HIGH
which doesn't make much sense for this fix because
From: Michal Hocko
vhost driver relies on copy_from_user/get_user from a kernel thread.
This makes it impossible to reap the memory of an oom victim which
shares mm with the vhost kernel thread because it could see a zero
page unexpectedly and theoretically make an incorrect decision visible
On Sat 18-06-16 03:09:02, Michael S. Tsirkin wrote:
> On Fri, Jun 17, 2016 at 11:00:17AM +0200, Michal Hocko wrote:
[...]
> > It seems that vhost usage would suffer from this problem because
> > it reads from the userspace to get (status) flags and makes some
> > decisions ba
On Sun 19-06-16 23:35:43, Michal Hocko wrote:
> On Sat 18-06-16 03:09:02, Michael S. Tsirkin wrote:
> > On Fri, Jun 17, 2016 at 11:00:17AM +0200, Michal Hocko wrote:
[...]
> > > /*
> > > + * A safe variant of __get_user for for use_mm() users to have a
> > >
On Sun 19-06-16 23:35:43, Michal Hocko wrote:
> On Sat 18-06-16 03:09:02, Michael S. Tsirkin wrote:
> > On Fri, Jun 17, 2016 at 11:00:17AM +0200, Michal Hocko wrote:
[...]
> > > diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
> > > index 349557825428..b1f3
erything is working fine. Allocations from irqs cannot be
[22798.508913] perfectly reliable and the kernel is designed to handle that.
[22798.508917] loop3: page allocation failure. order:0, mode:0x20,
alloc_flags:0x30 pflags:0x80208040
Signed-off-by: Michal Hocko
---
drivers/net/virtio_net.
On Tue 15-02-11 20:41:29, Rusty Russell wrote:
> On Tue, 15 Feb 2011 08:05:27 pm Michal Hocko wrote:
> > Hi,
> > we have started seeing a lot of allocator messages complaining about
> > failed allocations from virtnet_poll in soft IRQ. Could you consider the
> > followin
On Tue 15-02-11 10:35:27, Michal Hocko wrote:
[...]
> [22798.508903] The following is only an harmless informational message.
> [22798.508909] Unless you get a _continuous_flood_ of these messages it means
> [22798.508911] everything is working fine. Allocations from irqs cannot be
> [
On Tue 15-02-11 21:39:03, Rusty Russell wrote:
> On Tue, 15 Feb 2011 08:55:50 pm Michal Hocko wrote:
> > On Tue 15-02-11 20:41:29, Rusty Russell wrote:
> > > On Tue, 15 Feb 2011 08:05:27 pm Michal Hocko wrote:
> > > > Hi,
> > > > we have started seeing a l
dr - node->start),
> + node->size));
> s += size;
> addr += size;
> ++ret;
> --
> MST
--
Michal Hocko
SUSE Labs
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On Wed 11-09-19 08:25:03, Michael S. Tsirkin wrote:
> On Wed, Sep 11, 2019 at 02:16:28PM +0200, Michal Hocko wrote:
> > On Wed 11-09-19 08:10:00, Michael S. Tsirkin wrote:
> > > iovec addresses coming from vhost are assumed to be
> > > pre-validated, but in fact c
On Wed 11-09-19 09:03:10, Michael S. Tsirkin wrote:
> On Wed, Sep 11, 2019 at 02:33:16PM +0200, Michal Hocko wrote:
> > On Wed 11-09-19 08:25:03, Michael S. Tsirkin wrote:
> > > On Wed, Sep 11, 2019 at 02:16:28PM +0200, Michal Hocko wrote:
> > > > On Wed 11-09-19 08:1
I'll
> convert this to EXPORT_SYMBOL_GPL now that I know better :)
All other exports in this file are EXPORT_SYMBOL. Why is this one
considered special to restrict the access?
--
Michal Hocko
SUSE Labs
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
APIs
are EXPORT_SYMBOL so there should better be a good reason for this one
to differ. I can understand that this one is slightly different by
requesting a specific range of the memory but it is still under a full
control of the core MM to say no.
> Cc: Andrew Morton
> Cc: Michal Hocko
>
unt)
> + goto unmovable;
> continue;
> }
Do we really need to distinguish offline and hwpoison pages? They are
both unmovable for allocator purposes and offlineable for the hotplug,
right? Should we just hide them behin
ace.
I am also not really sure why do you want/need to control beyond the
offlining stage. Care to explain some more?
--
Michal Hocko
SUSE Labs
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On Wed 16-10-19 14:50:30, David Hildenbrand wrote:
> On 16.10.19 13:43, Michal Hocko wrote:
> > On Thu 19-09-19 16:22:25, David Hildenbrand wrote:
> > > virtio-mem wants to allow to offline memory blocks of which some parts
> > > were unplugged, especially, to later of
On Wed 16-10-19 15:45:06, David Hildenbrand wrote:
> On 16.10.19 13:43, Michal Hocko wrote:
> > On Thu 19-09-19 16:22:25, David Hildenbrand wrote:
> > > virtio-mem wants to allow to offline memory blocks of which some parts
> > > were unplugged, especially, to later of
On Wed 16-10-19 15:55:00, David Hildenbrand wrote:
> On 16.10.19 15:45, Michal Hocko wrote:
[...]
> > There is state stored in the struct page. In other words this shouldn't
> > be really different from HWPoison pages. I cannot find the code that is
> > doing that and
On Wed 16-10-19 16:14:52, David Hildenbrand wrote:
> On 16.10.19 16:03, Michal Hocko wrote:
[...]
> > But why cannot you keep the reference count at 1 (do get_page when
> > offlining the page)? In other words as long as the driver knows the page
> > has been returned to the
On Fri 18-10-19 10:50:24, David Hildenbrand wrote:
> On 18.10.19 10:15, Michal Hocko wrote:
> > On Wed 16-10-19 16:14:52, David Hildenbrand wrote:
> > > On 16.10.19 16:03, Michal Hocko wrote:
> > [...]
> > > > But why cannot you keep the reference count at 1 (do
On Fri 18-10-19 14:35:06, David Hildenbrand wrote:
> On 18.10.19 13:20, Michal Hocko wrote:
> > On Fri 18-10-19 10:50:24, David Hildenbrand wrote:
> > > On 18.10.19 10:15, Michal Hocko wrote:
[...]
> > > > for that - MEM_GOING_OFFLINE notification. This sounds lik
ropose in this patch (PageOffline() + refcount == 0)?
Simply skip over PageOffline pages. Reference count should never be != 0
at this stage.
> In summary, is what you suggest simply delaying setting the reference count
> to 0
> in MEM_GOING_OFFLINE instead of right away when the driver unpluggs the pages?
Yes
> What's the big benefit you see and I fail to see?
Aparat from no hooks into __put_page it is also an explicit control over
the page via reference counting. Do you see any downsides?
--
Michal Hocko
SUSE Labs
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
re we are effectively
waiting for pages to get freed finaly would be EAGAIN.
It is a bit late in the process because a large portion of the work has
been done already but this doesn't sound like something to lose sleep
over.
--
Michal Hocko
SUSE Labs
___
- memory
> will only be taken out of the balloon when really needed.
>
> Especially, a drop_slab() will result in the whole balloon getting
> deflated - undesired.
Could you explain why some more? drop_caches shouldn't be really used in
any production workloads and i
quiring callers to open code this general
patter?
> To keep things simple, allow to only work on a single memory block.
>
> Cc: Andrew Morton
> Cc: David Hildenbrand
> Cc: Oscar Salvador
> Cc: Michal Hocko
> Cc: Pavel Tatashin
> Cc: Wei Yang
> Cc: Dan Williams
ght inconsistency with the page cache droppint but nothing earth
shattering.
Acked-by: Michal Hocko
> ---
> fs/drop_caches.c | 4 +---
> mm/vmscan.c | 1 +
> 2 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/fs/drop_caches.c b/fs/drop_caches.c
> ind
(slab_mem_going_offline_callback).
The callback is quite dumb and it doesn't really try to free objects
from the given memory range or even try to drop active objects which
might turn out to be hard but this sounds like a more robust way to
achieve what you want.
> Cc: Andrew Mort
On Tue 25-02-20 16:09:29, David Hildenbrand wrote:
> On 25.02.20 15:58, Michal Hocko wrote:
> > On Thu 12-12-19 18:11:36, David Hildenbrand wrote:
> >> We already have a way to trigger reclaiming of all reclaimable slab objects
> >> from user space (echo 2 > /proc/sy
On Tue 25-02-20 15:27:28, David Hildenbrand wrote:
> On 25.02.20 15:11, Michal Hocko wrote:
> > On Thu 12-12-19 18:11:32, David Hildenbrand wrote:
> >> virtio-mem wants to offline and remove a memory block once it unplugged
> >> all subblocks (e.g., using alloc_con
ked-by: "Rafael J. Wysocki"
> Cc: Len Brown
> Cc: linux-a...@vger.kernel.org
> Signed-off-by: David Hildenbrand
Acked-by: Michal Hocko # for the export
> ---
> drivers/acpi/numa/srat.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/acpi/numa/s
ic anyway.
Maybe it is just a dejavu but I feel I have already said that but I do
not remember any details.
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: Vlastimil Babka
> Cc: Oscar Salvador
> Cc: Mel Gorman
> Cc: Mike Rapoport
> Cc: Dan Williams
> Cc: Alexander
orton
> Cc: David Hildenbrand
> Cc: Oscar Salvador
> Cc: Michal Hocko
> Cc: Pavel Tatashin
> Cc: Wei Yang
> Cc: Dan Williams
> Cc: Qian Cai
> Signed-off-by: David Hildenbrand
Acked-by: Michal Hocko
> ---
> include/linux/memory_hotplug.h | 1 +
> mm/memory_hot
On Mon 02-03-20 19:15:09, David Hildenbrand wrote:
[...]
> As requested by Michal, I will squash some patches.
Just to clarify. If I am the only one to care then do not bother.
Btw. I still have patch 6 on the todo list to review. I just didn't find
time for it today.
--
Michal Hocko
S
) +
> +sb_id * vm->subblock_size);
> + adjust_managed_page_count(pfn_to_page(pfn), nr_pages);
> + for (i = 0; i < nr_pages; i++)
> + page_ref_dec(pfn_to_page(pfn + i));
Is there ever situat
online_page_callback_t), resetting the page PageOffline() and
> not giving them to the buddy.
>
> Cc: Andrew Morton
> Cc: Juergen Gross
> Cc: Konrad Rzeszutek Wilk
> Cc: Pavel Tatashin
> Cc: Alexander Duyck
> Cc: Vlastimil Babka
> Cc: Johannes Weiner
> Cc:
On Tue 10-03-20 12:46:05, David Hildenbrand wrote:
> On 10.03.20 12:43, Michal Hocko wrote:
> > On Mon 02-03-20 14:49:37, David Hildenbrand wrote:
> > [...]
> >> +static void virtio_mem_notify_going_offline(struct virtio_mem *vm,
> >> +
understand whether we should teach kvmalloc_node
to understand GFP_REPEAT or there is no strong reason to keep the repeat
flag.
[1] http://lkml.kernel.org/r/20170102133700.1734-1-mho...@kernel.org
--
Michal Hocko
SUSE Labs
___
Virtualization mail
On Wed 04-01-17 19:56:42, Michael S. Tsirkin wrote:
> On Wed, Jan 04, 2017 at 04:08:00PM +0100, Michal Hocko wrote:
> > Hi Michael,
> > I am currently cleaning up opencoded kmalloc with vmalloc fallback users
> > [1] and my current kvmalloc_node helper doesn't support GF
; + *page = list_next_entry((*page), lru);
> + ret = 0;
> +out:
> + spin_unlock_irqrestore(&this_zone->lock, flags);
> + return ret;
> +}
> +EXPORT_SYMBOL(report_unused_page_block);
> +
> +#endif
> +
> static void zoneref_set_zone(struct zone *
t;
> static inline int zref_in_nodemask(struct zoneref *zref, nodemask_t *nodes)
> {
> --
> 2.7.4
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see:
On Fri 14-07-17 14:30:23, Michal Hocko wrote:
> On Wed 12-07-17 20:40:19, Wei Wang wrote:
> > This patch adds support for reporting blocks of pages on the free list
> > specified by the caller.
> >
> > As pages can leave the free list during this call or immediately
&
On Fri 14-07-17 22:17:13, Michael S. Tsirkin wrote:
> On Fri, Jul 14, 2017 at 02:30:23PM +0200, Michal Hocko wrote:
> > On Wed 12-07-17 20:40:19, Wei Wang wrote:
> > > This patch adds support for reporting blocks of pages on the free list
> > > specified by the caller
rence count, no? I
assume you do some sort of pfn walk and so you should be able to get an
access to the struct page.
--
Michal Hocko
SUSE Labs
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On Wed 19-07-17 20:01:18, Wei Wang wrote:
> On 07/19/2017 04:13 PM, Michal Hocko wrote:
[...
> >All you should need is the check for the page reference count, no? I
> >assume you do some sort of pfn walk and so you should be able to get an
> >access to the struct page.
>
On Tue 25-07-17 17:32:00, Wei Wang wrote:
> On 07/24/2017 05:00 PM, Michal Hocko wrote:
> >On Wed 19-07-17 20:01:18, Wei Wang wrote:
> >>On 07/19/2017 04:13 PM, Michal Hocko wrote:
> >[...
> >>>All you should need is the check for the page reference count, no
On Tue 25-07-17 19:56:24, Wei Wang wrote:
> On 07/25/2017 07:25 PM, Michal Hocko wrote:
> >On Tue 25-07-17 17:32:00, Wei Wang wrote:
> >>On 07/24/2017 05:00 PM, Michal Hocko wrote:
> >>>On Wed 19-07-17 20:01:18, Wei Wang wrote:
> >>>>On 07/19/2017 04:13
On Tue 25-07-17 14:47:16, Wang, Wei W wrote:
> On Tuesday, July 25, 2017 8:42 PM, hal Hocko wrote:
> > On Tue 25-07-17 19:56:24, Wei Wang wrote:
> > > On 07/25/2017 07:25 PM, Michal Hocko wrote:
> > > >On Tue 25-07-17 17:32:00, Wei Wang wrote:
> > > >&
On Wed 26-07-17 10:22:23, Wei Wang wrote:
> On 07/25/2017 10:53 PM, Michal Hocko wrote:
> >On Tue 25-07-17 14:47:16, Wang, Wei W wrote:
> >>On Tuesday, July 25, 2017 8:42 PM, hal Hocko wrote:
> >>>On Tue 25-07-17 19:56:24, Wei Wang wrote:
> >>>>On 07/25
cks tend to surivive for
longer. So I assume you would only care about larger free blocks. This
will also make the call cheaper.
--
Michal Hocko
SUSE Labs
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
> - __GFP_NOMEMALLOC | __GFP_NORETRY | __GFP_ZERO);
> +__GFP_NOMEMALLOC | __GFP_NORETRY);
> if (!page)
> return NULL;
>
> --
> 2.7.4
>
--
Michal Hocko
SUSE Labs
_
On Mon 31-07-17 15:41:49, Wei Wang wrote:
> On 07/31/2017 02:55 PM, Michal Hocko wrote:
> >On Mon 31-07-17 12:13:33, Wei Wang wrote:
> >>Ballooned pages will be marked as MADV_DONTNEED by the hypervisor and
> >>shouldn't be given to the host ksmd to scan.
On Mon 31-07-17 15:41:49, Wei Wang wrote:
> On 07/31/2017 02:55 PM, Michal Hocko wrote:
> >On Mon 31-07-17 12:13:33, Wei Wang wrote:
> >>Ballooned pages will be marked as MADV_DONTNEED by the hypervisor and
> >>shouldn't be given to the host ksmd to scan.
On Mon 31-07-17 16:23:26, ZhenweiPi wrote:
> On 07/31/2017 03:51 PM, Michal Hocko wrote:
>
> >On Mon 31-07-17 15:41:49, Wei Wang wrote:
> >>>On 07/31/2017 02:55 PM, Michal Hocko wrote:
> >>>> >On Mon 31-07-17 12:13:33, Wei Wang wrote:
> >>>&
either detect or prevent the use of such
> pages.
>
> Signed-off-by: Wei Wang
> Signed-off-by: Liang Li
> Cc: Michal Hocko
> Cc: Michael S. Tsirkin
> ---
> include/linux/mm.h | 7
> include/linux/mmzone
On Thu 03-08-17 18:42:15, Wei Wang wrote:
> On 08/03/2017 05:11 PM, Michal Hocko wrote:
> >On Thu 03-08-17 14:38:18, Wei Wang wrote:
[...]
> >>+static int report_free_page_block(struct zone *zone, unsigned int order,
> >>+ unsigned int migr
On Thu 03-08-17 19:27:19, Wei Wang wrote:
> On 08/03/2017 06:44 PM, Michal Hocko wrote:
> >On Thu 03-08-17 18:42:15, Wei Wang wrote:
> >>On 08/03/2017 05:11 PM, Michal Hocko wrote:
> >>>On Thu 03-08-17 14:38:18, Wei Wang wrote:
> >[...]
> >>>>+
On Thu 03-08-17 20:11:58, Wei Wang wrote:
> On 08/03/2017 07:28 PM, Michal Hocko wrote:
> >On Thu 03-08-17 19:27:19, Wei Wang wrote:
> >>On 08/03/2017 06:44 PM, Michal Hocko wrote:
> >>>On Thu 03-08-17 18:42:15, Wei Wang wrote:
> >>>>On 08/03/2017 05:1
a thread applies here
though.
> Signed-off-by: Wei Wang
> Cc: Michal Hocko
> Cc: Michael S. Tsirkin
other than that
Acked-by: Michal Hocko
> ---
> mm/balloon_compaction.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/balloon_compacti
On Thu 03-08-17 21:17:25, Wei Wang wrote:
> On 08/03/2017 08:41 PM, Michal Hocko wrote:
> >On Thu 03-08-17 20:11:58, Wei Wang wrote:
> >>On 08/03/2017 07:28 PM, Michal Hocko wrote:
> >>>On Thu 03-08-17 19:27:19, Wei Wang wrote:
> >>>>On 08/03/2017 06:4
On Fri 04-08-17 00:02:01, Michael S. Tsirkin wrote:
> On Thu, Aug 03, 2017 at 03:20:09PM +, Wang, Wei W wrote:
> > On Thursday, August 3, 2017 9:51 PM, Michal Hocko:
> > > As I've said earlier. Start simple optimize incrementally with some
> > > numbers to
On Fri 04-08-17 16:15:24, Wei Wang wrote:
> On 08/04/2017 03:53 PM, Michal Hocko wrote:
> >On Fri 04-08-17 00:02:01, Michael S. Tsirkin wrote:
> >>On Thu, Aug 03, 2017 at 03:20:09PM +, Wang, Wei W wrote:
> >>>On Thursday, August 3, 2017 9:51 PM, Michal Hocko:
>
balloon 7G pages is increased from ~491ms to 2.8 seconds with
> > __GFP_ZERO added. So, this patch removes the flag.
> >
> > Signed-off-by: Wei Wang
> > Cc: Michal Hocko
> > Cc: Michael S. Tsirkin
> > ---
> > mm/balloon_compaction.c | 2 +-
> > 1 f
On Tue 08-08-17 14:34:25, Wei Wang wrote:
> On 08/08/2017 02:12 PM, Wei Wang wrote:
> >On 08/03/2017 05:11 PM, Michal Hocko wrote:
> >>On Thu 03-08-17 14:38:18, Wei Wang wrote:
> >>This is just too ugly and wrong actually. Never provide struct page
> >>pointers
On Thu 10-08-17 15:38:34, Wei Wang wrote:
> On 08/10/2017 03:05 PM, Michal Hocko wrote:
> >On Tue 08-08-17 14:34:25, Wei Wang wrote:
> >>On 08/08/2017 02:12 PM, Wei Wang wrote:
> >>>On 08/03/2017 05:11 PM, Michal Hocko wrote:
> >>>>On Thu 03-08-17 14:
't be the first time I have seen
something like that.
> Signed-off-by: Wei Wang
> Signed-off-by: Liang Li
> Cc: Michal Hocko
> Cc: Michael S. Tsirkin
> ---
> include/linux/mm.h | 6 ++
> mm/page_alloc.c| 44
> 2
On Mon 21-08-17 14:12:47, Wei Wang wrote:
> On 08/18/2017 09:46 PM, Michal Hocko wrote:
[...]
> >>+/**
> >>+ * walk_free_mem_block - Walk through the free page blocks in the system
> >>+ * @opaque1: the context passed from the caller
> >>+ * @min_order: t
> 1. break out of list
> 2. remove page from the list
As I've said before this has to be a read only API. You cannot simply
fiddle with the page allocator internals under its feet.
> So I would make the callback bool, and I would use
> list_for_each_entry_safe.
If a bool would t
ly
iterate over remaining orders just to realize there is nothing to be
done for those...
> + }
> + spin_unlock_irqrestore(&zone->lock, flags);
> + }
> + }
> + }
> +}
> +EXPORT_SYM
On Mon 28-08-17 15:33:26, Michal Hocko wrote:
> On Mon 28-08-17 18:08:32, Wei Wang wrote:
> > This patch adds support to walk through the free page blocks in the
> > system and report them via a callback function. Some page blocks may
> > leave the free list after zone->lo
1 - 100 of 120 matches
Mail list logo
