Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1360332

Re: [RFC][PATCH v3 1/5] mm/zsmalloc: introduce class auto-compaction

From Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Newsgroups linux.kernel
Subject Re: [RFC][PATCH v3 1/5] mm/zsmalloc: introduce class auto-compaction
Date 2016-03-18 05:10 +0100
Message-ID <rdTTA-se-3@gated-at.bofh.it> (permalink)
References (5 earlier) <rcQuJ-6Fh-5@gated-at.bofh.it> <rduVc-ne-11@gated-at.bofh.it> <rdRf3-6Z3-7@gated-at.bofh.it> <rdRRM-7fe-9@gated-at.bofh.it> <rdTTA-se-5@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On (03/18/16 13:03), Minchan Kim wrote:
[..]
> > I have some concerns here. WQ_MEM_RECLAIM implies that there is a kthread
> > attached to wq, a rescuer thread, which will be idle until wq declares mayday.
> > But the kthread will be allocated anyway. And we can queue only one global
> > compaction work at a time; so wq does not buy us a lot here and a simple
> > wake_up_process() looks much better. it make sense to use wq if we can have
> > N compaction jobs queued, like I did in my initial patch, but otherwise
> > it's sort of overkill, isn't it?
[..]
> If we can use normal wq rather than WQ_MEM_RECLAIM, wq doesn't need
> own kthread attached the work. Right? If so, we can blow away that
> resource reservation problem.

right. if shrinker callbacks will be around (and it seems
they will), then we don't have to guarantee any forward
progress in background compaction. so yes, we can use normal
wq and there is no need in WQ_MEM_RECLAIM.

[..]
> > so you want to have
> > 
> > 	zs_free()
> > 		check pool watermark
> > 			queue class compaction
> 
> No queue class compaction.
> 
> > 			queue pool compaction
> 
> Yes. queue pool compaction.
> 
> > 
> > ?
> > 
> > I think a simpler one will be to just queue global compaction, if pool
> > is fragmented -- compact everything, like we do in shrinker callback.
> 
> That's what I said. :)

ah, ok.

	-ss

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

Re: [RFC][PATCH v3 1/5] mm/zsmalloc: introduce class auto-compaction Minchan Kim <minchan@kernel.org> - 2016-03-14 07:20 +0100
  Re: [RFC][PATCH v3 1/5] mm/zsmalloc: introduce class auto-compaction Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-03-14 08:50 +0100
    Re: [RFC][PATCH v3 1/5] mm/zsmalloc: introduce class auto-compaction Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-03-14 09:20 +0100
    Re: [RFC][PATCH v3 1/5] mm/zsmalloc: introduce class auto-compaction Minchan Kim <minchan@kernel.org> - 2016-03-15 01:50 +0100
      Re: [RFC][PATCH v3 1/5] mm/zsmalloc: introduce class auto-compaction Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-03-15 02:40 +0100
        Re: [RFC][PATCH v3 1/5] mm/zsmalloc: introduce class auto-compaction Minchan Kim <minchan@kernel.org> - 2016-03-15 07:20 +0100
          Re: [RFC][PATCH v3 1/5] mm/zsmalloc: introduce class auto-compaction Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-03-17 02:30 +0100
            Re: [RFC][PATCH v3 1/5] mm/zsmalloc: introduce class auto-compaction Minchan Kim <minchan@kernel.org> - 2016-03-18 02:20 +0100
              Re: [RFC][PATCH v3 1/5] mm/zsmalloc: introduce class auto-compaction Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-03-18 03:00 +0100
                Re: [RFC][PATCH v3 1/5] mm/zsmalloc: introduce class auto-compaction Minchan Kim <minchan@kernel.org> - 2016-03-18 05:10 +0100
                Re: [RFC][PATCH v3 1/5] mm/zsmalloc: introduce class auto-compaction Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-03-18 05:10 +0100

csiph-web