On Tue, Jul 03, 2018 at 11:44:29PM +0200, Sebastian Andrzej Siewior wrote: > On 2018-07-03 14:14:29 [-0700], Andrew Morton wrote: > > > > > Reply-To: "[PATCH 0/4] mm/list_lru": add.list_lru_shrink_walk_irq@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx () > > > > Well that's messed up. > > indeed it is. This should get into Subject: > > > On Tue, 3 Jul 2018 16:52:31 +0200 Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> wrote: > > > > > My intepretation of situtation is that Vladimir Davydon is fine patch #1 > > > and #2 of the series [0] but dislikes the irq argument and struct > > > member. It has been suggested to use list_lru_shrink_walk_irq() instead > > > the approach I went on in "mm: list_lru: Add lock_irq member to > > > __list_lru_init()". > > > > > > This series is based on the former two patches and introduces > > > list_lru_shrink_walk_irq() (and makes the third patch of series > > > obsolete). > > > In patch 1-3 I tried a tiny cleanup so the different locking > > > (spin_lock() vs spin_lock_irq()) is simply lifted to the caller of the > > > function. > > > > > > [0] The patch > > > mm: workingset: remove local_irq_disable() from count_shadow_nodes() > > > and > > > mm: workingset: make shadow_lru_isolate() use locking suffix > > > > > > > This isn't a very informative [0/n] changelog. Some overall summary of > > the patchset's objective, behaviour, use cases, testing results, etc. > > The patches should be threaded as a reply to 3/3 of the series so I > assumed it was enough. And while Vladimir complained about 2/3 and 3/3 > the discussion went on in 2/3 where he suggested to go on with the _irq > function. And testing, well with and without RT the function was invoked > as part of swapping (allocating memory until OOM) without complains. > > > I'm seeing significant conflicts with Kirill's "Improve shrink_slab() > > scalability (old complexity was O(n^2), new is O(n))" series, which I > > merged eight milliseconds ago. Kirill's patchset is large but fairly > > straightforward so I expect it's good for 4.18. So I suggest we leave > > things a week or more then please take a look at redoing this patchset > > on top of that work? > > If Vladimir is okay with to redo and nobody else complains then I could > rebase these four patches on top of your tree next week. IMHO this approach is more straightforward than the one with the per list_lru flag. For all patches, Reviewed-by: Vladimir Davydov <vdavydov.dev@xxxxxxxxx>
