Message ID | 20201112221543.3621014-1-guro@fb.com |
---|---|
Headers | show |
Series | bpf: switch to memcg-based memory accounting | expand |
Hi Roman, On Thu, 12 Nov 2020 14:15:10 -0800 Roman Gushchin <guro@fb.com> wrote: > > Patch series "mm: allow mapping accounted kernel pages to userspace", v6. > > Currently a non-slab kernel page which has been charged to a memory cgroup > can't be mapped to userspace. The underlying reason is simple: PageKmemcg > flag is defined as a page type (like buddy, offline, etc), so it takes a > bit from a page->mapped counter. Pages with a type set can't be mapped to > userspace. > ..... > > To make sure nobody uses a direct access, struct page's > mem_cgroup/obj_cgroups is converted to unsigned long memcg_data. > > Link: https://lkml.kernel.org/r/20201027001657.3398190-1-guro@fb.com > Link: https://lkml.kernel.org/r/20201027001657.3398190-2-guro@fb.com > Signed-off-by: Roman Gushchin <guro@fb.com> > Acked-by: Johannes Weiner <hannes@cmpxchg.org> > Reviewed-by: Shakeel Butt <shakeelb@google.com> > Acked-by: Michal Hocko <mhocko@suse.com> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> What is going on here? You are taking patches from linux-next and submitting them to another maintainer? Why? You should not do that from Andrew's tree as it changes/rebases every so often ... and you should not have my SOB on there as it is only there because that patch is in linux-next i.e. I in the submission chain to linux-next - if the patch is to go via some other tree, then my SOB should not be there. (The same may be true for Andrew's SOB.) In general you cannot add someone else's SOB to one of your patch submissions.
On Fri, Nov 13, 2020 at 09:56:32AM +1100, Stephen Rothwell wrote: > Hi Roman, > > On Thu, 12 Nov 2020 14:15:10 -0800 Roman Gushchin <guro@fb.com> wrote: > > > > Patch series "mm: allow mapping accounted kernel pages to userspace", v6. > > > > Currently a non-slab kernel page which has been charged to a memory cgroup > > can't be mapped to userspace. The underlying reason is simple: PageKmemcg > > flag is defined as a page type (like buddy, offline, etc), so it takes a > > bit from a page->mapped counter. Pages with a type set can't be mapped to > > userspace. > > > ..... > > > > To make sure nobody uses a direct access, struct page's > > mem_cgroup/obj_cgroups is converted to unsigned long memcg_data. > > > > Link: https://lkml.kernel.org/r/20201027001657.3398190-1-guro@fb.com > > Link: https://lkml.kernel.org/r/20201027001657.3398190-2-guro@fb.com > > Signed-off-by: Roman Gushchin <guro@fb.com> > > Acked-by: Johannes Weiner <hannes@cmpxchg.org> > > Reviewed-by: Shakeel Butt <shakeelb@google.com> > > Acked-by: Michal Hocko <mhocko@suse.com> > > Signed-off-by: Andrew Morton <akpm@linux-foundation.org> > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > > What is going on here? You are taking patches from linux-next and > submitting them to another maintainer? Why? Hi Stephen! These patches are not intended to be merged through the bpf tree. They are included into the patchset to make bpf selftests pass and for informational purposes. It's written in the cover letter. > > You should not do that from Andrew's tree as it changes/rebases every > so often ... and you should not have my SOB on there as it is only > there because that patch is in linux-next i.e. I in the submission > chain to linux-next - if the patch is to go via some other tree, then > my SOB should not be there. (The same may be true for Andrew's SOB.) > In general you cannot add someone else's SOB to one of your patch > submissions. I'm sorry for the confusion. Maybe I had to just list their titles in the cover letter. Idk what's the best option for such cross-subsystem dependencies. Thanks!
On Thu, Nov 12, 2020 at 04:26:10PM -0800, Roman Gushchin wrote: > > These patches are not intended to be merged through the bpf tree. > They are included into the patchset to make bpf selftests pass and for > informational purposes. > It's written in the cover letter. ... > Maybe I had to just list their titles in the cover letter. Idk what's > the best option for such cross-subsystem dependencies. We had several situations in the past releases where dependent patches were merged into multiple trees. For that to happen cleanly from git pov one of the maintainers need to create a stable branch/tag and let other maintainers pull that branch into different trees. This way the sha-s stay the same and no conflicts arise during the merge window. In this case sounds like the first 4 patches are in mm tree already. Is there a branch/tag I can pull to get the first 4 into bpf-next?
On Thu, 12 Nov 2020 19:04:56 -0800 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: > On Thu, Nov 12, 2020 at 04:26:10PM -0800, Roman Gushchin wrote: > > > > These patches are not intended to be merged through the bpf tree. > > They are included into the patchset to make bpf selftests pass and for > > informational purposes. > > It's written in the cover letter. > ... > > Maybe I had to just list their titles in the cover letter. Idk what's > > the best option for such cross-subsystem dependencies. > > We had several situations in the past releases where dependent patches > were merged into multiple trees. For that to happen cleanly from git pov > one of the maintainers need to create a stable branch/tag and let other > maintainers pull that branch into different trees. This way the sha-s > stay the same and no conflicts arise during the merge window. > In this case sounds like the first 4 patches are in mm tree already. > Is there a branch/tag I can pull to get the first 4 into bpf-next? Not really, at present. This is largely by design, although it does cause this problem once or twice a year. These four patches: mm-memcontrol-use-helpers-to-read-pages-memcg-data.patch mm-memcontrol-slab-use-helpers-to-access-slab-pages-memcg_data.patch mm-introduce-page-memcg-flags.patch mm-convert-page-kmemcg-type-to-a-page-memcg-flag.patch are sufficiently reviewed - please pull them into the bpf tree when convenient. Once they hit linux-next, I'll drop the -mm copies and the bpf tree maintainers will then be responsible for whether & when they get upstream.
On Thu, Nov 12, 2020 at 7:18 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > On Thu, 12 Nov 2020 19:04:56 -0800 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: > > > On Thu, Nov 12, 2020 at 04:26:10PM -0800, Roman Gushchin wrote: > > > > > > These patches are not intended to be merged through the bpf tree. > > > They are included into the patchset to make bpf selftests pass and for > > > informational purposes. > > > It's written in the cover letter. > > ... > > > Maybe I had to just list their titles in the cover letter. Idk what's > > > the best option for such cross-subsystem dependencies. > > > > We had several situations in the past releases where dependent patches > > were merged into multiple trees. For that to happen cleanly from git pov > > one of the maintainers need to create a stable branch/tag and let other > > maintainers pull that branch into different trees. This way the sha-s > > stay the same and no conflicts arise during the merge window. > > In this case sounds like the first 4 patches are in mm tree already. > > Is there a branch/tag I can pull to get the first 4 into bpf-next? > > Not really, at present. This is largely by design, although it does cause > this problem once or twice a year. > > These four patches: > > mm-memcontrol-use-helpers-to-read-pages-memcg-data.patch > mm-memcontrol-slab-use-helpers-to-access-slab-pages-memcg_data.patch > mm-introduce-page-memcg-flags.patch > mm-convert-page-kmemcg-type-to-a-page-memcg-flag.patch > > are sufficiently reviewed - please pull them into the bpf tree when > convenient. Once they hit linux-next, I'll drop the -mm copies and the > bpf tree maintainers will then be responsible for whether & when they > get upstream. That's certainly an option if they don't depend on other patches in the mm tree. Roman probably knows best ?
On Thu, 12 Nov 2020 19:25:48 -0800 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: > On Thu, Nov 12, 2020 at 7:18 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > > > On Thu, 12 Nov 2020 19:04:56 -0800 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: > > > > > On Thu, Nov 12, 2020 at 04:26:10PM -0800, Roman Gushchin wrote: > > > > > > > > These patches are not intended to be merged through the bpf tree. > > > > They are included into the patchset to make bpf selftests pass and for > > > > informational purposes. > > > > It's written in the cover letter. > > > ... > > > > Maybe I had to just list their titles in the cover letter. Idk what's > > > > the best option for such cross-subsystem dependencies. > > > > > > We had several situations in the past releases where dependent patches > > > were merged into multiple trees. For that to happen cleanly from git pov > > > one of the maintainers need to create a stable branch/tag and let other > > > maintainers pull that branch into different trees. This way the sha-s > > > stay the same and no conflicts arise during the merge window. > > > In this case sounds like the first 4 patches are in mm tree already. > > > Is there a branch/tag I can pull to get the first 4 into bpf-next? > > > > Not really, at present. This is largely by design, although it does cause > > this problem once or twice a year. > > > > These four patches: > > > > mm-memcontrol-use-helpers-to-read-pages-memcg-data.patch > > mm-memcontrol-slab-use-helpers-to-access-slab-pages-memcg_data.patch > > mm-introduce-page-memcg-flags.patch > > mm-convert-page-kmemcg-type-to-a-page-memcg-flag.patch > > > > are sufficiently reviewed - please pull them into the bpf tree when > > convenient. Once they hit linux-next, I'll drop the -mm copies and the > > bpf tree maintainers will then be responsible for whether & when they > > get upstream. > > That's certainly an option if they don't depend on other patches in the mm tree. > Roman probably knows best ? That should be OK. They apply and compile ;)
On Thu, Nov 12, 2020 at 07:25:48PM -0800, Alexei Starovoitov wrote: > On Thu, Nov 12, 2020 at 7:18 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > > > On Thu, 12 Nov 2020 19:04:56 -0800 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: > > > > > On Thu, Nov 12, 2020 at 04:26:10PM -0800, Roman Gushchin wrote: > > > > > > > > These patches are not intended to be merged through the bpf tree. > > > > They are included into the patchset to make bpf selftests pass and for > > > > informational purposes. > > > > It's written in the cover letter. > > > ... > > > > Maybe I had to just list their titles in the cover letter. Idk what's > > > > the best option for such cross-subsystem dependencies. > > > > > > We had several situations in the past releases where dependent patches > > > were merged into multiple trees. For that to happen cleanly from git pov > > > one of the maintainers need to create a stable branch/tag and let other > > > maintainers pull that branch into different trees. This way the sha-s > > > stay the same and no conflicts arise during the merge window. > > > In this case sounds like the first 4 patches are in mm tree already. > > > Is there a branch/tag I can pull to get the first 4 into bpf-next? > > > > Not really, at present. This is largely by design, although it does cause > > this problem once or twice a year. > > > > These four patches: > > > > mm-memcontrol-use-helpers-to-read-pages-memcg-data.patch > > mm-memcontrol-slab-use-helpers-to-access-slab-pages-memcg_data.patch > > mm-introduce-page-memcg-flags.patch > > mm-convert-page-kmemcg-type-to-a-page-memcg-flag.patch > > > > are sufficiently reviewed - please pull them into the bpf tree when > > convenient. Once they hit linux-next, I'll drop the -mm copies and the > > bpf tree maintainers will then be responsible for whether & when they > > get upstream. > > That's certainly an option if they don't depend on other patches in the mm tree. > Roman probably knows best ? Yes, they are self-contained and don't depend on any patches in the mm tree. Thanks!
On Thu, Nov 12, 2020 at 7:40 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > On Thu, 12 Nov 2020 19:25:48 -0800 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: > > > On Thu, Nov 12, 2020 at 7:18 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > > > > > On Thu, 12 Nov 2020 19:04:56 -0800 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: > > > > > > > On Thu, Nov 12, 2020 at 04:26:10PM -0800, Roman Gushchin wrote: > > > > > > > > > > These patches are not intended to be merged through the bpf tree. > > > > > They are included into the patchset to make bpf selftests pass and for > > > > > informational purposes. > > > > > It's written in the cover letter. > > > > ... > > > > > Maybe I had to just list their titles in the cover letter. Idk what's > > > > > the best option for such cross-subsystem dependencies. > > > > > > > > We had several situations in the past releases where dependent patches > > > > were merged into multiple trees. For that to happen cleanly from git pov > > > > one of the maintainers need to create a stable branch/tag and let other > > > > maintainers pull that branch into different trees. This way the sha-s > > > > stay the same and no conflicts arise during the merge window. > > > > In this case sounds like the first 4 patches are in mm tree already. > > > > Is there a branch/tag I can pull to get the first 4 into bpf-next? > > > > > > Not really, at present. This is largely by design, although it does cause > > > this problem once or twice a year. > > > > > > These four patches: > > > > > > mm-memcontrol-use-helpers-to-read-pages-memcg-data.patch > > > mm-memcontrol-slab-use-helpers-to-access-slab-pages-memcg_data.patch > > > mm-introduce-page-memcg-flags.patch > > > mm-convert-page-kmemcg-type-to-a-page-memcg-flag.patch > > > > > > are sufficiently reviewed - please pull them into the bpf tree when > > > convenient. Once they hit linux-next, I'll drop the -mm copies and the > > > bpf tree maintainers will then be responsible for whether & when they > > > get upstream. > > > > That's certainly an option if they don't depend on other patches in the mm tree. > > Roman probably knows best ? > > That should be OK. They apply and compile ;) Awesome. Thank you both for confirming. Will take them as soon as the rest of the set is reviewed.
On Thu, Nov 12, 2020 at 8:02 PM Roman Gushchin <guro@fb.com> wrote: > > On Thu, Nov 12, 2020 at 07:25:48PM -0800, Alexei Starovoitov wrote: > > On Thu, Nov 12, 2020 at 7:18 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > > > > > On Thu, 12 Nov 2020 19:04:56 -0800 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: > > > > > > > On Thu, Nov 12, 2020 at 04:26:10PM -0800, Roman Gushchin wrote: > > > > > > > > > > These patches are not intended to be merged through the bpf tree. > > > > > They are included into the patchset to make bpf selftests pass and for > > > > > informational purposes. > > > > > It's written in the cover letter. > > > > ... > > > > > Maybe I had to just list their titles in the cover letter. Idk what's > > > > > the best option for such cross-subsystem dependencies. > > > > > > > > We had several situations in the past releases where dependent patches > > > > were merged into multiple trees. For that to happen cleanly from git pov > > > > one of the maintainers need to create a stable branch/tag and let other > > > > maintainers pull that branch into different trees. This way the sha-s > > > > stay the same and no conflicts arise during the merge window. > > > > In this case sounds like the first 4 patches are in mm tree already. > > > > Is there a branch/tag I can pull to get the first 4 into bpf-next? > > > > > > Not really, at present. This is largely by design, although it does cause > > > this problem once or twice a year. > > > > > > These four patches: > > > > > > mm-memcontrol-use-helpers-to-read-pages-memcg-data.patch > > > mm-memcontrol-slab-use-helpers-to-access-slab-pages-memcg_data.patch > > > mm-introduce-page-memcg-flags.patch > > > mm-convert-page-kmemcg-type-to-a-page-memcg-flag.patch > > > > > > are sufficiently reviewed - please pull them into the bpf tree when > > > convenient. Once they hit linux-next, I'll drop the -mm copies and the > > > bpf tree maintainers will then be responsible for whether & when they > > > get upstream. > > > > That's certainly an option if they don't depend on other patches in the mm tree. > > Roman probably knows best ? > > Yes, they are self-contained and don't depend on any patches in the mm tree. > The patch "mm, kvm: account kvm_vcpu_mmap to kmemcg" in mm tree depends on that series.
On Fri, Nov 13, 2020 at 06:25:53AM -0800, Shakeel Butt wrote: > On Thu, Nov 12, 2020 at 8:02 PM Roman Gushchin <guro@fb.com> wrote: > > > > On Thu, Nov 12, 2020 at 07:25:48PM -0800, Alexei Starovoitov wrote: > > > On Thu, Nov 12, 2020 at 7:18 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > > > > > > > On Thu, 12 Nov 2020 19:04:56 -0800 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: > > > > > > > > > On Thu, Nov 12, 2020 at 04:26:10PM -0800, Roman Gushchin wrote: > > > > > > > > > > > > These patches are not intended to be merged through the bpf tree. > > > > > > They are included into the patchset to make bpf selftests pass and for > > > > > > informational purposes. > > > > > > It's written in the cover letter. > > > > > ... > > > > > > Maybe I had to just list their titles in the cover letter. Idk what's > > > > > > the best option for such cross-subsystem dependencies. > > > > > > > > > > We had several situations in the past releases where dependent patches > > > > > were merged into multiple trees. For that to happen cleanly from git pov > > > > > one of the maintainers need to create a stable branch/tag and let other > > > > > maintainers pull that branch into different trees. This way the sha-s > > > > > stay the same and no conflicts arise during the merge window. > > > > > In this case sounds like the first 4 patches are in mm tree already. > > > > > Is there a branch/tag I can pull to get the first 4 into bpf-next? > > > > > > > > Not really, at present. This is largely by design, although it does cause > > > > this problem once or twice a year. > > > > > > > > These four patches: > > > > > > > > mm-memcontrol-use-helpers-to-read-pages-memcg-data.patch > > > > mm-memcontrol-slab-use-helpers-to-access-slab-pages-memcg_data.patch > > > > mm-introduce-page-memcg-flags.patch > > > > mm-convert-page-kmemcg-type-to-a-page-memcg-flag.patch > > > > > > > > are sufficiently reviewed - please pull them into the bpf tree when > > > > convenient. Once they hit linux-next, I'll drop the -mm copies and the > > > > bpf tree maintainers will then be responsible for whether & when they > > > > get upstream. > > > > > > That's certainly an option if they don't depend on other patches in the mm tree. > > > Roman probably knows best ? > > > > Yes, they are self-contained and don't depend on any patches in the mm tree. > > > > The patch "mm, kvm: account kvm_vcpu_mmap to kmemcg" in mm tree > depends on that series. True, and I believe there are (or will be) more dependencies like this. But it should be fine, we only have to make sure that these 4 patches will be merged first. Thanks!