| Message ID | 20250315174930.1769599-1-shakeel.butt@linux.dev (mailing list archive) |
|---|---|
| Headers | show |
| Series | memcg: cleanup per-cpu stock | expand |
On Sat, 15 Mar 2025 10:49:21 -0700 Shakeel Butt <shakeel.butt@linux.dev> wrote: > > This is a cleanup series which is trying to simplify the memcg per-cpu > stock code, particularly it tries to remove unnecessary dependencies on > local_lock of per-cpu memcg stock. The eight patch from Vlastimil > optimizes the charge path by combining the charging and accounting. > > This series is based on next-20250314 plus two following patches: > > Link: https://lore.kernel.org/all/20250312222552.3284173-1-shakeel.butt@linux.dev/ > Link: https://lore.kernel.org/all/20250313054812.2185900-1-shakeel.butt@linux.dev/ Unfortunately the bpf tree has been making changes in the same area of memcontrol.c. 01d37228d331 ("memcg: Use trylock to access memcg stock_lock.") Sigh. We're at -rc7 and I don't think it's worth working around that for a cleanup series. So I'm inclined to just defer this series until the next -rc cycle. If BPF merges reasonably early in the next merge window then please promptly send this along and I should be able to squeak it into 6.15-rc1.
On Sat, Mar 15, 2025 at 08:57:59PM -0700, Andrew Morton wrote: > On Sat, 15 Mar 2025 10:49:21 -0700 Shakeel Butt <shakeel.butt@linux.dev> wrote: > > > > > This is a cleanup series which is trying to simplify the memcg per-cpu > > stock code, particularly it tries to remove unnecessary dependencies on > > local_lock of per-cpu memcg stock. The eight patch from Vlastimil > > optimizes the charge path by combining the charging and accounting. > > > > This series is based on next-20250314 plus two following patches: > > > > Link: https://lore.kernel.org/all/20250312222552.3284173-1-shakeel.butt@linux.dev/ > > Link: https://lore.kernel.org/all/20250313054812.2185900-1-shakeel.butt@linux.dev/ > > Unfortunately the bpf tree has been making changes in the same area of > memcontrol.c. 01d37228d331 ("memcg: Use trylock to access memcg > stock_lock.") > > Sigh. We're at -rc7 and I don't think it's worth working around that > for a cleanup series. So I'm inclined to just defer this series until > the next -rc cycle. > > If BPF merges reasonably early in the next merge window then please > promptly send this along and I should be able to squeak it into > 6.15-rc1. > Seems reasonable to me and thanks for taking a look.
On Sat, Mar 15, 2025 at 08:57:59PM -0700, Andrew Morton wrote: > On Sat, 15 Mar 2025 10:49:21 -0700 Shakeel Butt <shakeel.butt@linux.dev> wrote: > > > > > This is a cleanup series which is trying to simplify the memcg per-cpu > > stock code, particularly it tries to remove unnecessary dependencies on > > local_lock of per-cpu memcg stock. The eight patch from Vlastimil > > optimizes the charge path by combining the charging and accounting. > > > > This series is based on next-20250314 plus two following patches: > > > > Link: https://lore.kernel.org/all/20250312222552.3284173-1-shakeel.butt@linux.dev/ > > Link: https://lore.kernel.org/all/20250313054812.2185900-1-shakeel.butt@linux.dev/ > > Unfortunately the bpf tree has been making changes in the same area of > memcontrol.c. 01d37228d331 ("memcg: Use trylock to access memcg > stock_lock.") > > Sigh. We're at -rc7 and I don't think it's worth working around that > for a cleanup series. So I'm inclined to just defer this series until > the next -rc cycle. > > If BPF merges reasonably early in the next merge window then please > promptly send this along and I should be able to squeak it into > 6.15-rc1. Ohh. I didn't realize that try_alloc changes are causing so much trouble. Sorry about that. Andrew, could you please instead take bpf-next.git try_alloc_pages branch into your tree and resolve two trivial conflicts: 1. https://lore.kernel.org/bpf/20250311120422.1d9a8f80@canb.auug.org.au/ 2. https://lore.kernel.org/bpf/20250312145247.380c2aa5@canb.auug.org.au/ There are 7 commits there. You can also squash Vlastimil's fix "Fix the flipped condition in gfpflags_allow_spinning" into "Introduce try_alloc_pages" patch or keep everything as-is. I'll drop it from bpf-next right after. Then Shakeel can rebase/resend his set without conflicts and everything will be nicely ready for the merge window. I'll defer other bpf side things to after merge window when trees converge. Thanks!
On Sun, Mar 16, 2025 at 08:59:20AM -0700, Alexei Starovoitov wrote: > On Sat, Mar 15, 2025 at 08:57:59PM -0700, Andrew Morton wrote: > > On Sat, 15 Mar 2025 10:49:21 -0700 Shakeel Butt <shakeel.butt@linux.dev> wrote: > > > > > > > > This is a cleanup series which is trying to simplify the memcg per-cpu > > > stock code, particularly it tries to remove unnecessary dependencies on > > > local_lock of per-cpu memcg stock. The eight patch from Vlastimil > > > optimizes the charge path by combining the charging and accounting. > > > > > > This series is based on next-20250314 plus two following patches: > > > > > > Link: https://lore.kernel.org/all/20250312222552.3284173-1-shakeel.butt@linux.dev/ > > > Link: https://lore.kernel.org/all/20250313054812.2185900-1-shakeel.butt@linux.dev/ > > > > Unfortunately the bpf tree has been making changes in the same area of > > memcontrol.c. 01d37228d331 ("memcg: Use trylock to access memcg > > stock_lock.") > > > > Sigh. We're at -rc7 and I don't think it's worth working around that > > for a cleanup series. So I'm inclined to just defer this series until > > the next -rc cycle. > > > > If BPF merges reasonably early in the next merge window then please > > promptly send this along and I should be able to squeak it into > > 6.15-rc1. > > Ohh. I didn't realize that try_alloc changes are causing so much trouble. > Sorry about that. > > Andrew, > > could you please instead take bpf-next.git try_alloc_pages branch > into your tree and resolve two trivial conflicts: > 1. https://lore.kernel.org/bpf/20250311120422.1d9a8f80@canb.auug.org.au/ > 2. https://lore.kernel.org/bpf/20250312145247.380c2aa5@canb.auug.org.au/ > There are 7 commits there. > You can also squash Vlastimil's fix > "Fix the flipped condition in gfpflags_allow_spinning" into > "Introduce try_alloc_pages" patch or keep everything as-is. > > I'll drop it from bpf-next right after. > > Then Shakeel can rebase/resend his set without conflicts and everything > will be nicely ready for the merge window. Thanks Alexei. Andrew, if you decide to take try_alloc_pages branch into mm-tree, then this series should apply cleanly as it is based on next-20250314 which already have all the try_alloc_pages patches and the conflict resolutions.
On Sun, 16 Mar 2025 08:59:20 -0700 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: > On Sat, Mar 15, 2025 at 08:57:59PM -0700, Andrew Morton wrote: > > On Sat, 15 Mar 2025 10:49:21 -0700 Shakeel Butt <shakeel.butt@linux.dev> wrote: > > > > > > > > This is a cleanup series which is trying to simplify the memcg per-cpu > > > stock code, particularly it tries to remove unnecessary dependencies on > > > local_lock of per-cpu memcg stock. The eight patch from Vlastimil > > > optimizes the charge path by combining the charging and accounting. > > > > > > This series is based on next-20250314 plus two following patches: > > > > > > Link: https://lore.kernel.org/all/20250312222552.3284173-1-shakeel.butt@linux.dev/ > > > Link: https://lore.kernel.org/all/20250313054812.2185900-1-shakeel.butt@linux.dev/ > > > > Unfortunately the bpf tree has been making changes in the same area of > > memcontrol.c. 01d37228d331 ("memcg: Use trylock to access memcg > > stock_lock.") > > > > Sigh. We're at -rc7 and I don't think it's worth working around that > > for a cleanup series. So I'm inclined to just defer this series until > > the next -rc cycle. > > > > If BPF merges reasonably early in the next merge window then please > > promptly send this along and I should be able to squeak it into > > 6.15-rc1. > > Ohh. I didn't realize that try_alloc changes are causing so much trouble. > Sorry about that. > > Andrew, > > could you please instead take bpf-next.git try_alloc_pages branch > into your tree and resolve two trivial conflicts: > 1. https://lore.kernel.org/bpf/20250311120422.1d9a8f80@canb.auug.org.au/ > 2. https://lore.kernel.org/bpf/20250312145247.380c2aa5@canb.auug.org.au/ > There are 7 commits there. > You can also squash Vlastimil's fix > "Fix the flipped condition in gfpflags_allow_spinning" into > "Introduce try_alloc_pages" patch or keep everything as-is. > > I'll drop it from bpf-next right after. > > Then Shakeel can rebase/resend his set without conflicts and everything > will be nicely ready for the merge window. > > I'll defer other bpf side things to after merge window when trees converge. Let's just leave things as they are, please. It's only a cleanup series and merging cleanups after -rc7 is rather dubious even without issues such as these.