Re: [PATCH] staging:wlan-ng: use memdup_user instead of kmalloc/copy_from_user

2021-02-15 Thread Michal Hocko
nge of req->len though? If this can be larger than PAGE_SIZE then vmemdup_user would be a better alternative. -- Michal Hocko SUSE Labs ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2] binder: Don't use mmput() from shrinker function.

2020-07-16 Thread Michal Hocko
start __mmput() from shrinker context. > > [1] > https://syzkaller.appspot.com/bug?id=bc9e7303f537c41b2b0cc2dfcea3fc42964c2d45 > > Reported-by: syzbot > Reported-by: syzbot > Signed-off-by: Tetsuo Handa Reviewed-by: Michal Hocko Thanks! > --- > drivers/android/bin

Re: [PATCH] binder: Don't use mmput() from shrinker function.

2020-07-16 Thread Michal Hocko
On Thu 16-07-20 22:41:14, Tetsuo Handa wrote: > On 2020/07/16 17:35, Michal Hocko wrote: [...] > > But in order for this to happen the shrinker would have to do the last > > put on the mm. But mm cannot go away from under uprobe_mmap so those two > > paths cannot race with eac

Re: [PATCH] binder: Don't use mmput() from shrinker function.

2020-07-16 Thread Michal Hocko
,7 @@ enum lru_status binder_alloc_free_page(struct list_head > *item, > trace_binder_unmap_user_end(alloc, index); > } > mmap_read_unlock(mm); > - mmput(mm); > + mmput_async(mm); > > trace_binder_unmap_kernel_start(alloc, index); > &g

Re: possible deadlock in shmem_fallocate (4)

2020-07-14 Thread Michal Hocko
n your backing inode. But asking lockdep experts would be better than relying on my vague recollection -- Michal Hocko SUSE Labs ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: possible deadlock in shmem_fallocate (4)

2020-07-14 Thread Michal Hocko
On Tue 14-07-20 22:08:59, Hillf Danton wrote: > > On Tue, 14 Jul 2020 10:26:29 +0200 Michal Hocko wrote: > > On Tue 14-07-20 13:32:05, Hillf Danton wrote: > > > > > > On Mon, 13 Jul 2020 20:41:11 -0700 Eric Biggers wrote: > > > > On Tue, Jul 14, 20

Re: possible deadlock in shmem_fallocate (4)

2020-07-14 Thread Michal Hocko
*range), lru); I do not think this is an appropriate fix. First of all is this a real deadlock or a lockdep false positive? Is it possible that ashmem just needs to properly annotate its shmem inodes? Or is it possible that the internal backing shmem file is visible to the userspace so the

Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()

2020-06-17 Thread Michal Hocko
On Wed 17-06-20 05:23:21, Matthew Wilcox wrote: > On Wed, Jun 17, 2020 at 01:31:57PM +0200, Michal Hocko wrote: > > On Wed 17-06-20 04:08:20, Matthew Wilcox wrote: > > > If you call vfree() under > > > a spinlock, you're in trouble. in_atomic() only knows

Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()

2020-06-17 Thread Michal Hocko
On Wed 17-06-20 04:08:20, Matthew Wilcox wrote: > On Wed, Jun 17, 2020 at 09:12:12AM +0200, Michal Hocko wrote: > > On Tue 16-06-20 17:37:11, Matthew Wilcox wrote: > > > Not just performance critical, but correctness critical. Since kvfree() > > > may allocate from the

Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()

2020-06-17 Thread Michal Hocko
locate from the vmalloc allocator, I really think that kvfree() > should assert that it's !in_atomic(). Otherwise we can get into trouble > if we end up calling vfree() and have to take the mutex. FWIW __vfree already checks for atomic context and put the work into a deferred context. S

Re: [PATCH v4 1/3] mm/slab: Use memzero_explicit() in kzfree()

2020-06-15 Thread Michal Hocko
;slab: introduce kzfree()") > Cc: sta...@vger.kernel.org > Signed-off-by: Waiman Long Acked-by: Michal Hocko Although I am not really sure this is a stable material. Is there any known instance where the memset was optimized out from kzfree? > --- > mm/slab_common.c | 2

Re: [PATCH 1/2] mm, treewide: Rename kzfree() to kfree_sensitive()

2020-04-14 Thread Michal Hocko
free_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 Makes sense. I haven't checked all the conversions and will rely on the s

Re: [PATCH 00/34] put_user_pages(): miscellaneous call sites

2019-08-07 Thread Michal Hocko
On Wed 07-08-19 10:37:26, Jan Kara wrote: > On Fri 02-08-19 12:14:09, John Hubbard wrote: > > On 8/2/19 7:52 AM, Jan Kara wrote: > > > On Fri 02-08-19 07:24:43, Matthew Wilcox wrote: > > > > On Fri, Aug 02, 2019 at 02:41:46PM +0200, Jan Kara wrote: > > > >

Re: [PATCH 00/34] put_user_pages(): miscellaneous call sites

2019-08-02 Thread Michal Hocko
e changes that would break the balance though. -- Michal Hocko SUSE Labs ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android

2019-05-07 Thread Michal Hocko
ing two OOM killer implementations in the kernel. As already pointed out newer kernels can do PSI and older kernels can live with an out of tree code to achieve what they need. I do not see why we really need this code in the upstream kernel. -- Michal Hocko SUSE Labs

Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android

2019-03-12 Thread Michal Hocko
again with the whole system really sluggish. That is what PSI is trying to help with. -- Michal Hocko SUSE Labs ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android

2019-03-12 Thread Michal Hocko
On Tue 12-03-19 09:37:41, Sultan Alsawaf wrote: > On Tue, Mar 12, 2019 at 09:05:32AM +0100, Michal Hocko wrote: > > The only way to control the OOM behavior pro-actively is to throttle > > allocation speed. We have memcg high limit for that purpose. Along with > > PSI, I can

Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android

2019-03-12 Thread Michal Hocko
On Tue 12-03-19 16:33:15, Michal Hocko wrote: > On Tue 12-03-19 08:25:41, Matthew Wilcox wrote: > > On Tue, Mar 12, 2019 at 09:05:32AM +0100, Michal Hocko wrote: > > > On Mon 11-03-19 15:15:35, Suren Baghdasaryan wrote: > > > > Yeah, killing speed is a well-known pr

Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android

2019-03-12 Thread Michal Hocko
On Tue 12-03-19 08:25:41, Matthew Wilcox wrote: > On Tue, Mar 12, 2019 at 09:05:32AM +0100, Michal Hocko wrote: > > On Mon 11-03-19 15:15:35, Suren Baghdasaryan wrote: > > > Yeah, killing speed is a well-known problem which we are considering > > > in LMKD. For exampl

Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android

2019-03-12 Thread Michal Hocko
is to throttle allocation speed. We have memcg high limit for that purpose. Along with PSI, I can imagine a reasonably working user space early oom notifications and reasonable acting upon that. -- Michal Hocko SUSE Labs ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android

2019-03-11 Thread Michal Hocko
fork.c > index 9dcd18aa2..162c45392 100644 > --- a/kernel/fork.c > +++ b/kernel/fork.c > @@ -1881,6 +1881,9 @@ static __latent_entropy struct task_struct > *copy_process( > p->sequential_io= 0; > p->sequential_io_avg= 0; > #endif > +#ifdef CONFIG_ANDROID_SIMPLE_LMK > + p->slmk_sigkill_sent = false; > +#endif > > /* Perform scheduler related setup. Assign this task to a CPU. */ > retval = sched_fork(clone_flags, p); > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 3eb01dedf..fd0d697c6 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -67,6 +67,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -967,6 +968,11 @@ static inline void __free_one_page(struct page *page, > } > } > > +#ifdef CONFIG_ANDROID_SIMPLE_LMK > + if (simple_lmk_page_in(page, order, migratetype)) > + return; > +#endif > + > list_add(&page->lru, &zone->free_area[order].free_list[migratetype]); > out: > zone->free_area[order].nr_free++; > @@ -4427,6 +4433,13 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int > order, > if (costly_order && !(gfp_mask & __GFP_RETRY_MAYFAIL)) > goto nopage; > > +#ifdef CONFIG_ANDROID_SIMPLE_LMK > + page = simple_lmk_oom_alloc(order, ac->migratetype); > + if (page) > + prep_new_page(page, order, gfp_mask, alloc_flags); > + goto got_pg; > +#endif > + > if (should_reclaim_retry(gfp_mask, order, ac, alloc_flags, >did_some_progress > 0, &no_progress_loops)) > goto retry; > -- > 2.21.0 -- Michal Hocko SUSE Labs ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH RFCv2 0/4] mm/memory_hotplug: Introduce memory block types

2018-12-20 Thread Michal Hocko
w, I am doing it just like > > the other types (e.g. online_type) we are using in that context. > > - The "removable" property should never have been named like that. It > > should have been "offlinable". Can we still rename that? E.g. boot

Re: [PATCH v1 7/8] PM / Hibernate: use pfn_to_online_page()

2018-11-19 Thread Michal Hocko
Andrew Morton > Cc: Matthew Wilcox > Cc: Michal Hocko > Cc: "Michael S. Tsirkin" > Suggested-by: Michal Hocko > Signed-off-by: David Hildenbrand I have only a very vague understanding of this specific code but I do not really see any real reason for checking offl

Re: [PATCH RFC 6/6] PM / Hibernate: exclude all PageOffline() pages

2018-11-15 Thread Michal Hocko
ly do not want to touch offline pfn ranges in general. A separate patch for that of course. Thanks! -- Michal Hocko SUSE Labs ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH RFC 2/6] mm: convert PG_balloon to PG_offline

2018-11-15 Thread Michal Hocko
hen virtio-balloon pages were always marked > with PG_balloon. So the documentation is actually wrong ("balloon page" > vs. "balloon compaction page"). > > I have no idea who actually used that information. I suspect this was > just some debugg

Re: [PATCH RFC 3/6] kexec: export PG_offline to VMCOREINFO

2018-11-15 Thread Michal Hocko
page state. I am not really sure what is the concern here exactly. Kdump is so closly tight to the specific kernel version that the api exported specifically for its purpose cannot be seriously considered an ABI. Kdump has to adopt all the time. -- Michal Hocko SUSE Labs ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v5 1/2] memory_hotplug: Free pages as higher order

2018-10-19 Thread Michal Hocko
On Thu 18-10-18 19:18:25, Andrew Morton wrote: [...] > So this patch needs more work, yes? Yes, I've talked to Arun (he is offline until next week) offlist and he will play with this some more. -- Michal Hocko SUSE Labs ___ devel mailing

Re: [PATCH v5 1/2] memory_hotplug: Free pages as higher order

2018-10-11 Thread Michal Hocko
> > https://lore.kernel.org/patchwork/patch/989445/ > > Looks like deferred_free_range() has the same problem calling > __free_pages_core() to adjust zone->managed_pages. deferred initialization has one thread per node AFAIR so we cannot race on managed_pages updates. Wel

Re: [PATCH v5 1/2] memory_hotplug: Free pages as higher order

2018-10-11 Thread Michal Hocko
On Thu 11-10-18 07:59:32, Arun KS wrote: > On 2018-10-10 23:03, Michal Hocko wrote: > > On Wed 10-10-18 22:26:41, Arun KS wrote: > > > On 2018-10-10 21:00, Vlastimil Babka wrote: > > > > On 10/5/18 10:10 AM, Arun KS wrote: > > > > > When free pa

Re: [PATCH v5 1/2] memory_hotplug: Free pages as higher order

2018-10-10 Thread Michal Hocko
_lock. Are we safe without the lock? If yes, there > > should perhaps be a comment explaining why. > > Looks unsafe without managed_page_count_lock. Why does it matter actually? We cannot online/offline memory in parallel. This is not the case for the boot where we initialize memory in par

Re: [PATCH v5 1/2] memory_hotplug: Free pages as higher order

2018-10-09 Thread Michal Hocko
On Tue 09-10-18 15:24:13, Arun KS wrote: > On 2018-10-09 14:59, Michal Hocko wrote: > > On Fri 05-10-18 13:40:05, Arun KS wrote: > > > When free pages are done with higher order, time spend on > > > coalescing pages by buddy allocator can be reduced. With > >

Re: [PATCH v5 2/2] mm/page_alloc: remove software prefetching in __free_pages_core

2018-10-09 Thread Michal Hocko
+, p++) { > - prefetchw(p + 1); > + for (loop = 0; loop < nr_pages ; loop++, p++) { > __ClearPageReserved(p); > set_page_count(p, 0); > } > - __ClearPageReserved(p); > - set_page_count(p, 0); > > page_zone(page)-&

Re: [PATCH v5 1/2] memory_hotplug: Free pages as higher order

2018-10-09 Thread Michal Hocko
; improving the hot add latency by 60%. Modify external > providers of online callback to align with the change. Acked-by: Michal Hocko Thanks for your patience with all the resubmission. -- Michal Hocko SUSE Labs ___ devel mailing list de...@linuxdriv

Re: [PATCH v4] memory_hotplug: Free pages as higher order

2018-10-04 Thread Michal Hocko
__ClearPageReserved(p); > set_page_count(p, 0); > } > - __ClearPageReserved(p); > - set_page_count(p, 0); > > page_zone(page)->managed_pages += nr_pages; > set_page_refcounted(page); I think this is wort a separa

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

2018-10-03 Thread Michal Hocko
g to enable them anyway (e.g. RAS would require to have movable_node kernel parameters, ballooning a kernel module etc.). Really, one udev script to rule them all will simply never work. -- Michal Hocko SUSE Labs ___ devel mailing

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

2018-10-03 Thread Michal Hocko
ree that allocating that from the zone normal and off node is not great. Especially the second part which is noticeable for whole node hotplug. I have a feeling that arguing about fork not able to proceed or OOMing for the memory hotplug is a bit of a stretch and a sign a of misconfiguration. -- Michal Hocko SUSE Labs ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

2018-10-03 Thread Michal Hocko
d of days here trying to come up with > an onlining solution which would work for everyone and eBPF would move > this decision to distro level. The point is that there is _no_ general onlining solution. This is basically policy which belongs to the userspa

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

2018-10-03 Thread Michal Hocko
On Tue 02-10-18 17:25:19, David Hildenbrand wrote: > On 02/10/2018 15:47, Michal Hocko wrote: [...] > > Zone imbalance is an inherent problem of the highmem zone. It is > > essentially the highmem zone we all loved so much back in 32b days. > > Yes the movable zone doesn&

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

2018-10-03 Thread Michal Hocko
On Wed 03-10-18 15:38:04, Vitaly Kuznetsov wrote: > David Hildenbrand writes: > > > On 02/10/2018 15:47, Michal Hocko wrote: > ... > >> > >> Why do you need a generic hotplug rule in the first place? Why don't you > >> simply provide different

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

2018-10-02 Thread Michal Hocko
On Mon 01-10-18 11:34:25, David Hildenbrand wrote: > On 01/10/2018 10:40, Michal Hocko wrote: > > On Fri 28-09-18 17:03:57, David Hildenbrand wrote: > > [...] > > > > I haven't read the patch itself but I just wanted to note one thing > > about this part &g

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

2018-10-01 Thread Michal Hocko
purpose. You said that distributions have hard time to distinguish different types of onlinining policies but isn't this something that is inherently usecase specific? -- Michal Hocko SUSE Labs ___ devel mailing list de...@linuxdriverproject.org h

Re: [PATCH v2] memory_hotplug: Free pages as higher order

2018-09-25 Thread Michal Hocko
On Tue 25-09-18 11:59:09, Vlastimil Babka wrote: [...] > This seems like almost complete copy of __free_pages_boot_core(), could > you do some code reuse instead? I think Michal Hocko also suggested that. Yes, please try to reuse as much code as possible -- Michal Hocko SUS

Re: [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required

2018-07-26 Thread Michal Hocko
On Thu 26-07-18 21:37:05, Baoquan He wrote: > On 07/26/18 at 03:14pm, Michal Hocko wrote: > > On Thu 26-07-18 15:12:42, Michal Hocko wrote: > > > On Thu 26-07-18 21:09:04, Baoquan He wrote: > > > > On 07/26/18 at 02:59pm, Michal Hocko wrote: > > > > &g

Re: [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required

2018-07-26 Thread Michal Hocko
On Thu 26-07-18 15:12:42, Michal Hocko wrote: > On Thu 26-07-18 21:09:04, Baoquan He wrote: > > On 07/26/18 at 02:59pm, Michal Hocko wrote: > > > On Wed 25-07-18 14:48:13, Baoquan He wrote: > > > > On 07/23/18 at 04:34pm, Michal Hocko wrote: > > > > &g

Re: [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required

2018-07-26 Thread Michal Hocko
On Thu 26-07-18 21:09:04, Baoquan He wrote: > On 07/26/18 at 02:59pm, Michal Hocko wrote: > > On Wed 25-07-18 14:48:13, Baoquan He wrote: > > > On 07/23/18 at 04:34pm, Michal Hocko wrote: > > > > On Thu 19-07-18 23:17:53, Baoquan He wrote: > > > > >

Re: [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required

2018-07-26 Thread Michal Hocko
On Wed 25-07-18 14:48:13, Baoquan He wrote: > On 07/23/18 at 04:34pm, Michal Hocko wrote: > > On Thu 19-07-18 23:17:53, Baoquan He wrote: > > > Kexec has been a formal feature in our distro, and customers owning > > > those kind of very large machine can make use of thi

Re: [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required

2018-07-23 Thread Michal Hocko
do not have the full context here but let me note that you should be careful when doing top-down reservation because you can easily get into hotplugable memory and break the hotremove usecase. We even warn when this is done. See memblock_find_in_range_no

Re: [RFC PATCH] binder: Don't require the binder lock when killed in binder_thread_read()

2017-04-04 Thread Michal Hocko
On Tue 04-04-17 08:10:03, Doug Anderson wrote: > Hi, > > On Tue, Apr 4, 2017 at 12:40 AM, Michal Hocko wrote: [...] > > So the primary question is what are you trying to achieve? > > Ideally it would be nice to bring back patches to make the OOM > handling lockup f

Re: [RFC PATCH] binder: Don't require the binder lock when killed in binder_thread_read()

2017-04-04 Thread Michal Hocko
On Mon 03-04-17 11:09:32, Doug Anderson wrote: [...] > Maybe +Michal Hocko would have some opinions of which OOM Reaper > patches would be good for picking into linux stable? I am lacking context here but please note that the OOM reaper patches alone are not sufficient to make the OOM ha

Re: [PATCH] staging, android: remove lowmemory killer from the tree

2017-03-09 Thread Michal Hocko
On Thu 09-03-17 10:30:28, Greg KH wrote: > On Thu, Mar 09, 2017 at 10:15:13AM +0100, Michal Hocko wrote: > > Greg, do you see any obstacle to have this merged. The discussion so far > > shown that a) vendors are not using the code as is b) there seems to be > > an agreemen

Re: [PATCH] staging, android: remove lowmemory killer from the tree

2017-03-09 Thread Michal Hocko
Greg, do you see any obstacle to have this merged. The discussion so far shown that a) vendors are not using the code as is b) there seems to be an agreement that something else than we have in the kernel is really needed. On Wed 22-02-17 13:01:21, Michal Hocko wrote: > From: Michal Ho

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

2017-03-06 Thread Michal Hocko
On Mon 06-03-17 11:40:41, Daniel Vetter wrote: > On Mon, Mar 06, 2017 at 08:42:59AM +0100, Michal Hocko wrote: > > On Fri 03-03-17 09:37:55, Laura Abbott wrote: > > > On 03/03/2017 05:29 AM, Michal Hocko wrote: > > > > On Thu 02-03-17 13:44:32, L

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

2017-03-05 Thread Michal Hocko
On Fri 03-03-17 09:37:55, Laura Abbott wrote: > On 03/03/2017 05:29 AM, Michal Hocko wrote: > > On Thu 02-03-17 13:44:32, Laura Abbott wrote: > >> Hi, > >> > >> There's been some recent discussions[1] about Ion-like frameworks. There's > >>

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

2017-03-03 Thread Michal Hocko
aging is to discuss any > other changes to the ABI people might want. Once this comes out of staging, > I really don't want to mess with the ABI. Could you recapitulate concerns preventing the code being merged normally rather than through the staging tree and how they were addressed

Re: [PATCH] staging, android: remove lowmemory killer from the tree

2017-02-24 Thread Michal Hocko
On Fri 24-02-17 16:40:13, peter enderborg wrote: > On 02/24/2017 04:03 PM, Michal Hocko wrote: > > On Fri 24-02-17 15:42:49, peter enderborg wrote: > >> On 02/24/2017 03:11 PM, Michal Hocko wrote: > >>> On Fri 24-02-17 14:16:34, peter enderborg wrote: > >>

Re: [PATCH] staging, android: remove lowmemory killer from the tree

2017-02-24 Thread Michal Hocko
On Fri 24-02-17 15:42:49, peter enderborg wrote: > On 02/24/2017 03:11 PM, Michal Hocko wrote: > > On Fri 24-02-17 14:16:34, peter enderborg wrote: > >> On 02/24/2017 01:28 PM, Michal Hocko wrote: > > [...] > >>> Yeah, I strongly believe that the chosen approac

Re: [PATCH] staging, android: remove lowmemory killer from the tree

2017-02-24 Thread Michal Hocko
On Fri 24-02-17 14:16:34, peter enderborg wrote: > On 02/24/2017 01:28 PM, Michal Hocko wrote: [...] > > Yeah, I strongly believe that the chosen approach is completely wrong. > > Both in abusing the shrinker interface and abusing oom_score_adj as the > > only criteri

Re: [PATCH] staging, android: remove lowmemory killer from the tree

2017-02-24 Thread Michal Hocko
ntinue unless > we get google-android to be part of it. Hocko objected heavy on > the patches but seems not to see that we need something to > do the job before we can disconnect from shrinker. Yeah, I strongly believe that the chosen approach is completely wrong. Both in abusing the shrinker interface and abusing oom_score_adj as the only criterion for the oom victim selection. -- Michal Hocko SUSE Labs ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging, android: remove lowmemory killer from the tree

2017-02-24 Thread Michal Hocko
On Thu 23-02-17 12:24:57, John Stultz wrote: > On Wed, Feb 22, 2017 at 4:01 AM, Michal Hocko wrote: > > From: Michal Hocko > > > > Lowmemory killer is sitting in the staging tree since 2008 without any > > serious interest for fixing issues brought up by the MM folks

Re: [PATCH] staging, android: remove lowmemory killer from the tree

2017-02-24 Thread Michal Hocko
3e32cb2e0a12 ("mm: memcontrol: lockless page counters") has improved situation a lot as all the charging is lockless since then (3.19). -- Michal Hocko SUSE Labs ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging, android: remove lowmemory killer from the tree

2017-02-22 Thread Michal Hocko
From: Michal Hocko Lowmemory killer is sitting in the staging tree since 2008 without any serious interest for fixing issues brought up by the MM folks. The main objection is that the implementation is basically broken by design: - it hooks into slab shrinker API which is not suitable

Re: [PATCH 0/3 staging-next] android: Lowmemmorykiller task tree

2017-02-20 Thread Michal Hocko
On Mon 13-02-17 16:42:42, peter enderborg wrote: > On 02/10/2017 11:27 AM, Michal Hocko wrote: > > [I have only now see this cover - it answers some of the questions I've > > had to specific patches. It would be really great if you could use git > > send-email to post p

Re: [PATCH 0/3 staging-next] android: Lowmemmorykiller task tree

2017-02-10 Thread Michal Hocko
ficiency problem and a solution. > > Lowmemorykiller in android has a severe efficiency problem. The basic > problem is that the registered shrinker gets called very often without > anything actually happening. Which is an inherent problem because lkml doesn't belong to shrinkers i

Re: [PATCH 1/3 staging-next] android: Collect statistics from lowmemorykiller

2017-02-10 Thread Michal Hocko
On Fri 10-02-17 10:05:34, peter enderborg wrote: > On 02/10/2017 08:59 AM, Michal Hocko wrote: [...] > > The approach was wrong from the day 1. Abusing slab shrinkers > > is just a bad place to stick this logic. This all belongs to the > > userspace. > > But now it is

Re: [PATCH 1/3 staging-next] android: Collect statistics from lowmemorykiller

2017-02-10 Thread Michal Hocko
at. So rather than trying to fix unfixable I would stronly suggest focusing on making vmpressure work reliably. -- Michal Hocko SUSE Labs ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 3/3 staging-next] mm: Remove RCU and tasklocks from lmk

2017-02-09 Thread Michal Hocko
On Fri 10-02-17 08:39:11, peter enderborg wrote: > On 02/09/2017 09:05 PM, Michal Hocko wrote: > > On Thu 09-02-17 14:21:52, peter enderborg wrote: > >> Fundamental changes: > >> 1 Does NOT take any RCU lock in shrinker functions. > >> 2 It returns same result f

Re: [PATCH 1/3 staging-next] android: Collect statistics from lowmemorykiller

2017-02-09 Thread Michal Hocko
On Thu 09-02-17 21:07:37, Greg KH wrote: > On Thu, Feb 09, 2017 at 08:26:41PM +0100, Michal Hocko wrote: > > On Thu 09-02-17 14:21:45, peter enderborg wrote: > > > This collects stats for shrinker calls and how much > > > waste work we do within the lowmemorykiller. &g

Re: [PATCH 3/3 staging-next] mm: Remove RCU and tasklocks from lmk

2017-02-09 Thread Michal Hocko
value then no task will get into the tree. Or am I missing something really obvious here? Moreover oom scores tend to be mostly same for tasks. That means that your sorted tree will become sorted by pids in most cases. I do not see any sorting based on the rss nor any updates that

Re: [PATCH 1/3 staging-next] android: Collect statistics from lowmemorykiller

2017-02-09 Thread Michal Hocko
ed a stable user API. This is a no-go, especially for something that is still lingering in the staging tree without any actuall effort to make it fully supported MM feature. I am actually strongly inclined to simply drop lmk from the tree completely. > Signed-off-by: Peter Enderborg Nacked-by

Re: [PATCH 2/3 staging-next] oom: Add notification for oom_score_adj

2017-02-09 Thread Michal Hocko
On Thu 09-02-17 14:21:49, peter enderborg wrote: > This adds subscribtion for changes in oom_score_adj, this > value is important to android systems. Why? Who is user of this API? -- Michal Hocko SUSE Labs ___ devel mailing l

Re: [PATCH] android,lowmemorykiller: Don't abuse TIF_MEMDIE.

2016-03-08 Thread Michal Hocko
that the flags are not scarce which doesn't seem to be the case here). The LMK cannot kill the frozen tasks now but this shouldn't be a big deal because this is not strictly necessary for the system to move on. We are not OOM. > Signed-off-by: Tetsuo Handa > Cc: Michal Hocko &

Re: [PATCH] mm: add MM_SWAPENTS and page table when calculate tasksize in lowmem_scan()

2016-02-17 Thread Michal Hocko
s used for other reasons. > > I'd seriously consider not accepting any additional hacks on top of this > code until the implementation is rewritten. Fully agreed! -- Michal Hocko SUSE Labs ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 2/2] android, lmk: Reverse the order of setting TIF_MEMDIE and sending SIGKILL.

2015-09-04 Thread Michal Hocko
On Wed 02-09-15 18:06:20, Greg KH wrote: [...] > And if we aren't taking patch 1/2, I guess this one isn't needed either? Unlike the patch1 which was pretty much cosmetic this fixes a real issue. -- Michal Hocko SUSE Labs ___ devel ma

Re: [PATCH 2/2] android, lmk: Reverse the order of setting TIF_MEMDIE and sending SIGKILL.

2015-08-27 Thread Michal Hocko
; > This patch reverts commit 6bc2b856bb7c ("staging: android: lowmemorykiller: > set TIF_MEMDIE before send kill sig"), for oom_kill_process() was updated > to send SIGKILL before setting TIF_MEMDIE. > > Signed-off-by: Tetsuo Handa Acked-by: Michal Hocko > --- >

Re: [PATCH RESEND 0/3] memory_hotplug: hyperv: fix deadlock between memory adding and onlining

2015-03-12 Thread Michal Hocko
On Mon 09-03-15 09:40:43, Vitaly Kuznetsov wrote: > Michal Hocko writes: > > > [Sorry for the late response] > > > > This is basically the same code posted by KY Srinivasan posted late last > > year (http://marc.info/?l=linux-mm&m=141782228129426&w=2). I ha

Re: [PATCH RESEND 0/3] memory_hotplug: hyperv: fix deadlock between memory adding and onlining

2015-03-06 Thread Michal Hocko
driver core: export lock_device_hotplug/unlock_device_hotplug > memory_hotplug: add note about holding device_hotplug_lock and > add_memory() > Drivers: hv: balloon: fix deadlock between memory adding and onlining > > drivers/base/core.c | 2 ++ > drivers/hv/hv_balloo

Re: [PATCH] lowmemorykiller: Avoid excessive/redundant calling of LMK

2015-01-15 Thread Michal Hocko
Inc. is a > member of the Code Aurora Forum, hosted by The Linux Foundation > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't emai

Re: [PATCH 2/2] Drivers: hv: balloon: Fix the deadlock issue in the memory hot-add code

2014-12-11 Thread Michal Hocko
On Thu 11-12-14 00:21:09, KY Srinivasan wrote: > > > > -Original Message- > > From: Michal Hocko [mailto:mho...@suse.cz] > > Sent: Tuesday, December 9, 2014 2:56 AM > > To: Yasuaki Ishimatsu > > Cc: KY Srinivasan; gre...@linuxfoundation.org; l

Re: [PATCH 2/2] Drivers: hv: balloon: Fix the deadlock issue in the memory hot-add code

2014-12-09 Thread Michal Hocko
On Tue 09-12-14 19:25:50, Yasuaki Ishimatsu wrote: > (2014/12/09 18:08), Michal Hocko wrote: [...] > >Doesn't udev retry the operation if it gets EBUSY or EAGAIN? > > It depend on implementation of udev.rules. So we can retry online/offline > operation in udev.rules.

Re: [PATCH 2/2] Drivers: hv: balloon: Fix the deadlock issue in the memory hot-add code

2014-12-09 Thread Michal Hocko
On Tue 09-12-14 10:23:51, Yasuaki Ishimatsu wrote: > (2014/12/09 0:04), Michal Hocko wrote: > >On Fri 05-12-14 16:41:38, K. Y. Srinivasan wrote: > >>Andy Whitcroft initially saw this deadlock. We > >>have seen this as well. Here is the original description of the &

Re: [PATCH 2/2] Drivers: hv: balloon: Fix the deadlock issue in the memory hot-add code

2014-12-08 Thread Michal Hocko
unlock_device_hotplug(); > > if (ret) { > pr_info("hot_add memory failed error is %d\n", ret); > -- > 1.7.4.1 > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord

Re: [PATCH staging] zcache: fix "zcache=" kernel parameter

2013-07-25 Thread Michal Hocko
"goto out" directive inside the "if (!ret)" statement > 2. In case that crypto_has_comp() returned 0, change the value of ret >to non-zero before "goto out" to indicate an error. > > This patch replaces an earlier one from Michal Hocko (based on rep

Re: [PATCH 1/1] Drivers: base: memory: Export symbols for onlining memory blocks

2013-07-25 Thread Michal Hocko
the memory after having succeeded in hot adding > > the > > memory. > > I think we should hold off on this patch and other like it until we've > been sufficiently able to explain how (b) happens. Agreed. -- Michal Hocko SUSE Labs _

Re: Re: [PATCH] zcache: fix "zcache=" kernel parameter

2013-07-24 Thread Michal Hocko
On Wed 24-07-13 12:32:32, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Wednesday, July 24, 2013 12:04:41 PM Michal Hocko wrote: > > On Wed 24-07-13 12:02:35, Michal Hocko wrote: > > > I have posted a similar fix quite some time ago and I guess Greg should > >

Re: [PATCH] zcache: fix "zcache=" kernel parameter

2013-07-24 Thread Michal Hocko
On Wed 24-07-13 12:02:35, Michal Hocko wrote: > I have posted a similar fix quite some time ago and I guess Greg should > already have it. For reference https://lkml.org/lkml/2013/6/26/410 > Greg? > > On Fri 19-07-13 16:46:41, Piotr Sarna wrote: > > Commit 835f2f5 (&qu

Re: [PATCH] zcache: fix "zcache=" kernel parameter

2013-07-24 Thread Michal Hocko
} > if (!ret) > strcpy(zcache_comp_name, "lzo"); > -- > 1.7.9.5 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org &

Re: [PATCH 1/1] Drivers: base: memory: Export symbols for onlining memory blocks

2013-07-23 Thread Michal Hocko
On Tue 23-07-13 14:52:36, KY Srinivasan wrote: > > > > -Original Message- > > From: Michal Hocko [mailto:mho...@suse.cz] > > Sent: Monday, July 22, 2013 8:37 AM > > To: KY Srinivasan > > Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org;

Re: [PATCH 1/1] Drivers: base: memory: Export symbols for onlining memory blocks

2013-07-22 Thread Michal Hocko
> #ifdef CONFIG_MEMORY_HOTREMOVE > extern int unregister_memory_section(struct mem_section *); > #endif > -- > 1.7.4.1 > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more i