Re: [PATCH] Revert "mm/vunmap: add cond_resched() in vunmap_pmd_range"

* Sergey Senozhatsky [201118 02:07]: > On (20/11/17 12:29), Minchan Kim wrote: > > Yub, I remeber the discussion. > > https://lore.kernel.org/linux-mm/20200416203736.gb50...@google.com/ > > > > I wanted to remove it but 30% gain made me think again before > > deciding to drop it. > > Since it co

Re: [PATCH] Revert "mm/vunmap: add cond_resched() in vunmap_pmd_range"

On (20/11/17 12:29), Minchan Kim wrote: > Yub, I remeber the discussion. > https://lore.kernel.org/linux-mm/20200416203736.gb50...@google.com/ > > I wanted to remove it but 30% gain made me think again before > deciding to drop it. > Since it continue to make problems and Linux is approaching to

Re: [PATCH] Revert "mm/vunmap: add cond_resched() in vunmap_pmd_range"

On Tue, Nov 17, 2020 at 01:56:32PM +, Christoph Hellwig wrote: > Btw, I remember that the whole vmalloc magic in zsmalloc was only giving > a small benefit for a few niche use cases. Given that it generally has > very strange interaction with the vmalloc core, including using various > APIs no

Re: [PATCH] Revert "mm/vunmap: add cond_resched() in vunmap_pmd_range"

Btw, I remember that the whole vmalloc magic in zsmalloc was only giving a small benefit for a few niche use cases. Given that it generally has very strange interaction with the vmalloc core, including using various APIs not used by any driver I'm going to ask once again why we can't just drop the

Re: [PATCH] Revert "mm/vunmap: add cond_resched() in vunmap_pmd_range"

> > Let's cc Uladzislau on vmalloc things? > > > How about this? > > Well, lol, that's a simple approach to avoiding the problem ;) > To me it looks like a specific workaround for a specific one user. > > unmap_kernel_range had been atomic operation and zsmalloc has used > > it in atomic conte

Re: [PATCH] Revert "mm/vunmap: add cond_resched() in vunmap_pmd_range"

Let's cc Uladzislau on vmalloc things? > How about this? Well, lol, that's a simple approach to avoiding the problem ;) > unmap_kernel_range had been atomic operation and zsmalloc has used > it in atomic context in zs_unmap_object. > However, ("e47110e90584, mm/vunmap: add cond_resched() in vu

Re: [PATCH] Revert "mm/vunmap: add cond_resched() in vunmap_pmd_range"

On Fri, Nov 13, 2020 at 08:25:29AM -0800, Minchan Kim wrote: > On Thu, Nov 12, 2020 at 02:49:19PM -0800, Andrew Morton wrote: > > On Thu, 12 Nov 2020 12:01:01 -0800 Minchan Kim wrote: > > > > > > > > On Sat, Nov 07, 2020 at 12:39:39AM -0800, Minchan Kim wrote: > > > > Hi Andrew, > > > > > > > >

Re: [PATCH] Revert "mm/vunmap: add cond_resched() in vunmap_pmd_range"

On Thu, Nov 12, 2020 at 02:49:19PM -0800, Andrew Morton wrote: > On Thu, 12 Nov 2020 12:01:01 -0800 Minchan Kim wrote: > > > > > On Sat, Nov 07, 2020 at 12:39:39AM -0800, Minchan Kim wrote: > > > Hi Andrew, > > > > > > On Fri, Nov 06, 2020 at 05:59:33PM -0800, Andrew Morton wrote: > > > > On Th

Re: [PATCH] Revert "mm/vunmap: add cond_resched() in vunmap_pmd_range"

On Thu, 12 Nov 2020 12:01:01 -0800 Minchan Kim wrote: > > On Sat, Nov 07, 2020 at 12:39:39AM -0800, Minchan Kim wrote: > > Hi Andrew, > > > > On Fri, Nov 06, 2020 at 05:59:33PM -0800, Andrew Morton wrote: > > > On Thu, 5 Nov 2020 09:02:49 -0800 Minchan Kim wrote: > > > > > > > This reverts c

Re: [PATCH] Revert "mm/vunmap: add cond_resched() in vunmap_pmd_range"

Hi Andrew, How should we proceed this problem? On Sat, Nov 07, 2020 at 12:39:39AM -0800, Minchan Kim wrote: > Hi Andrew, > > On Fri, Nov 06, 2020 at 05:59:33PM -0800, Andrew Morton wrote: > > On Thu, 5 Nov 2020 09:02:49 -0800 Minchan Kim wrote: > > > > > This reverts commit e47110e90584a22e99

Re: [PATCH] Revert "mm/vunmap: add cond_resched() in vunmap_pmd_range"

On Sat, Nov 07, 2020 at 12:39:39AM -0800, Minchan Kim wrote: > Hi Andrew, > > On Fri, Nov 06, 2020 at 05:59:33PM -0800, Andrew Morton wrote: > > On Thu, 5 Nov 2020 09:02:49 -0800 Minchan Kim wrote: > > > > > This reverts commit e47110e90584a22e9980510b00d0dfad3a83354e. > > > > > > While I was

Re: [PATCH] Revert "mm/vunmap: add cond_resched() in vunmap_pmd_range"

Hi Andrew, On Fri, Nov 06, 2020 at 05:59:33PM -0800, Andrew Morton wrote: > On Thu, 5 Nov 2020 09:02:49 -0800 Minchan Kim wrote: > > > This reverts commit e47110e90584a22e9980510b00d0dfad3a83354e. > > > > While I was doing zram testing, I found sometimes decompression failed > > since the comp

Re: [PATCH] Revert "mm/vunmap: add cond_resched() in vunmap_pmd_range"

On Thu, 5 Nov 2020 09:02:49 -0800 Minchan Kim wrote: > This reverts commit e47110e90584a22e9980510b00d0dfad3a83354e. > > While I was doing zram testing, I found sometimes decompression failed > since the compression buffer was corrupted. With investigation, > I found below commit calls cond_res

Re: [PATCH] Revert "mm/vunmap: add cond_resched() in vunmap_pmd_range"

On Thu, Nov 05, 2020 at 05:16:02PM +, Matthew Wilcox wrote: > On Thu, Nov 05, 2020 at 09:02:49AM -0800, Minchan Kim wrote: > > This reverts commit e47110e90584a22e9980510b00d0dfad3a83354e. > > > > While I was doing zram testing, I found sometimes decompression failed > > since the compression

Re: [PATCH] Revert "mm/vunmap: add cond_resched() in vunmap_pmd_range"

On Thu, Nov 05, 2020 at 09:02:49AM -0800, Minchan Kim wrote: > This reverts commit e47110e90584a22e9980510b00d0dfad3a83354e. > > While I was doing zram testing, I found sometimes decompression failed > since the compression buffer was corrupted. With investigation, > I found below commit calls con

[PATCH] Revert "mm/vunmap: add cond_resched() in vunmap_pmd_range"

This reverts commit e47110e90584a22e9980510b00d0dfad3a83354e. While I was doing zram testing, I found sometimes decompression failed since the compression buffer was corrupted. With investigation, I found below commit calls cond_resched unconditionally so it could make a problem in atomic context