Re: [PATCH v7 REBASED 00/17] Improve shrink_slab() scalability (old complexity was O(n^2), new is O(n))

On Mon, 2 Jul 2018 12:10:47 +0300 Kirill Tkhai wrote: > Hi, Andrew, > > this series is made on top of 4.18-rc1, while now I see > "mm-list_lru-add-lock_irq-member-to-__list_lru_init.patch" > in mm tree, which conflicts with two of patches from series. Well, "mm: use irq locking suffix instead

Re: [PATCH v7 REBASED 00/17] Improve shrink_slab() scalability (old complexity was O(n^2), new is O(n))

On Mon, 2 Jul 2018 12:10:47 +0300 Kirill Tkhai wrote: > Hi, Andrew, > > this series is made on top of 4.18-rc1, while now I see > "mm-list_lru-add-lock_irq-member-to-__list_lru_init.patch" > in mm tree, which conflicts with two of patches from series. Well, "mm: use irq locking suffix instead

Re: [PATCH v7 REBASED 00/17] Improve shrink_slab() scalability (old complexity was O(n^2), new is O(n))

Hi, Andrew, this series is made on top of 4.18-rc1, while now I see "mm-list_lru-add-lock_irq-member-to-__list_lru_init.patch" in mm tree, which conflicts with two of patches from series. Should I rebase the series on top of current mm tree? What are you plans on this series? Strange thing, I

Re: [PATCH v7 REBASED 00/17] Improve shrink_slab() scalability (old complexity was O(n^2), new is O(n))

Hi, Andrew, this series is made on top of 4.18-rc1, while now I see "mm-list_lru-add-lock_irq-member-to-__list_lru_init.patch" in mm tree, which conflicts with two of patches from series. Should I rebase the series on top of current mm tree? What are you plans on this series? Strange thing, I

[PATCH v7 REBASED 00/17] Improve shrink_slab() scalability (old complexity was O(n^2), new is O(n))

Hi, this patches solves the problem with slow shrink_slab() occuring on the machines having many shrinkers and memory cgroups (i.e., with many containers). The problem is complexity of shrink_slab() is O(n^2) and it grows too fast with the growth of containers numbers. Let we have 200

[PATCH v7 REBASED 00/17] Improve shrink_slab() scalability (old complexity was O(n^2), new is O(n))

Hi, this patches solves the problem with slow shrink_slab() occuring on the machines having many shrinkers and memory cgroups (i.e., with many containers). The problem is complexity of shrink_slab() is O(n^2) and it grows too fast with the growth of containers numbers. Let we have 200

[PATCH v7 REBASED 00/17] Improve shrink_slab() scalability (old complexity was O(n^2), new is O(n))

Hi, this patches solves the problem with slow shrink_slab() occuring on the machines having many shrinkers and memory cgroups (i.e., with many containers). The problem is complexity of shrink_slab() is O(n^2) and it grows too fast with the growth of containers numbers. Let we have 200

[PATCH v7 REBASED 00/17] Improve shrink_slab() scalability (old complexity was O(n^2), new is O(n))

Hi, this patches solves the problem with slow shrink_slab() occuring on the machines having many shrinkers and memory cgroups (i.e., with many containers). The problem is complexity of shrink_slab() is O(n^2) and it grows too fast with the growth of containers numbers. Let we have 200