From: Michal Hocko <mhocko@suse.com> To: Jesse Barnes <jsbarnes@google.com> Cc: Yu Zhao <yuzhao@google.com>, Andrew Morton <akpm@linux-foundation.org>, Linus Torvalds <torvalds@linux-foundation.org>, Andi Kleen <ak@linux.intel.com>, Catalin Marinas <catalin.marinas@arm.com>, Dave Hansen <dave.hansen@linux.intel.com>, Hillf Danton <hdanton@sina.com>, Jens Axboe <axboe@kernel.dk>, Johannes Weiner <hannes@cmpxchg.org>, Jonathan Corbet <corbet@lwn.net>, Matthew Wilcox <willy@infradead.org>, Mel Gorman <mgorman@suse.de>, Michael Larabel <Michael@michaellarabel.com>, Rik van Riel <riel@surriel.com>, Vlastimil Babka <vbabka@suse.cz>, Will Deacon <will@kernel.org>, Ying Huang <ying.huang@intel.com>, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, linux-mm@kvack.org, page-reclaim@google.com, X86 ML <x86@kernel.org> Subject: Re: [PATCH v6 0/9] Multigenerational LRU Framework Date: Tue, 11 Jan 2022 11:40:55 +0100 [thread overview] Message-ID: <Yd1et2VFOX4xxgly@dhcp22.suse.cz> (raw) In-Reply-To: <CAJmaN=n=kn9-gC8if5wp8Gfj7uN+QVrX0ex=9JPXC7rPvGf1Qg@mail.gmail.com> On Mon 10-01-22 14:46:08, Jesse Barnes wrote: > > > > 2. There have been none that came with the testing/benchmarking > > > > coverage as this one did. Please point me to some if I'm mistaken, > > > > and I'll gladly match them. > > > > > > I do appreciate your numbers but you should realize that this is an area > > > that is really hard to get any conclusive testing for. > > > > Fully agreed. That's why we started a new initiative, and we hope more > > people will following these practices: > > 1. All results in this area should be reported with at least standard > > deviations, or preferably confidence intervals. > > 2. Real applications should be benchmarked (with synthetic load > > generator), not just synthetic benchmarks (not real applications). > > 3. A wide range of devices should be covered, i.e., servers, desktops, > > laptops and phones. > > > > I'm very confident to say our benchmark reports were hold to the > > highest standards. We have worked with MariaDB (company), EnterpriseDB > > (Postgres), Redis (company), etc. on these reports. They have copies > > of these reports (PDF version): > > https://linux-mm.googlesource.com/benchmarks/ > > > > We welcome any expert in those applications to examine our reports, > > and we'll be happy to run any other benchmarks or same benchmarks with > > different configurations that anybody thinks it's important and we've > > missed. > > I really think this gets at the heart of the issue with mm > development, and is one of the reasons it's been extra frustrating to > not have an MM conf for the past couple of years; I think sorting out > how we measure & proceed on changes would be easier done f2f. E.g. > concluding with a consensus that if something doesn't regress on X, Y, > and Z, and has reasonably maintainable and readable code, we should > merge it and try it out. I am fully with you on that! I hope we can have LSFMM this year finally. > But since f2f isn't an option until 2052 at the earliest... Let's be more optimistic than that ;) > I understand the desire for an "incremental approach that gets us from > A->B". In the abstract it sounds great. However, with a change like > this one, I think it's highly likely that such a path would be > littered with regressions both large and small, and would probably be > more difficult to reason about than the relatively clean design of > MGLRU. There are certainly things that do not make much sense to split up of course. On the other hand the patchset is making a lot of decisions and assumptions that are neither documented in the code nor in the changelog. From my past experience these are really problematic from a long term maintenance POV. We are struggling with those already because changelog tend to be much more coarse in the past yet the code stays with us and we have been really "great" at not touching many of those because "something might break". This results in the complexity grow and further maintenance burden. > On top of that, I don't think we'll get the kind of user > feedback we need for something like this *without* merging it. Yu has > done a tremendous job collecting data here (and the results are really > incredible), but I think we can all agree that without extensive > testing in the field with all sorts of weird codes, we're not going to > find the problematic behaviors we're concerned about. This is understood. > So unless we want to eschew big mm changes entirely (we shouldn't! > look at net or scheduling for how important big rewrites are to > progress), I think we should be open to experimenting with new stuff. > We can always revert if things get too unwieldy. As long as the patchset doesn't include new user visible interfaces which have proven to be really hard to revert. > None of this is to say that there may not be lots more comments on the > code or potential fixes/changes to incorporate before merging; I'm > mainly arguing about the mindset we should have to changes like this, > not all the stuff the community is already really good at (i.e. > testing and reviewing code on a nuts & bolts level). From my reading of this and previous discussions I have gathered that there was no opposition just for the sake of it. There have been very specific questions regarding the implementation and/or future plans to address issues expressed in the past. So far I have only managed to check the memcg and oom integration finding some issues there. All of them should be fixable reasonably easily but it also points that a deep dive into this is really necessary. I have also raised questions about future maintainability of the resulting code. As you could have noticed the review power in the MM community is lacking behind and we tend to have more code producers than reviewers and maintainers. Not to mention other things like page flags depletion which is something we have been struggling for quite some time already. All that being said there is a lot of work for such a large change to be merged. -- Michal Hocko SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@suse.com> To: Jesse Barnes <jsbarnes@google.com> Cc: Yu Zhao <yuzhao@google.com>, Andrew Morton <akpm@linux-foundation.org>, Linus Torvalds <torvalds@linux-foundation.org>, Andi Kleen <ak@linux.intel.com>, Catalin Marinas <catalin.marinas@arm.com>, Dave Hansen <dave.hansen@linux.intel.com>, Hillf Danton <hdanton@sina.com>, Jens Axboe <axboe@kernel.dk>, Johannes Weiner <hannes@cmpxchg.org>, Jonathan Corbet <corbet@lwn.net>, Matthew Wilcox <willy@infradead.org>, Mel Gorman <mgorman@suse.de>, Michael Larabel <Michael@michaellarabel.com>, Rik van Riel <riel@surriel.com>, Vlastimil Babka <vbabka@suse.cz>, Will Deacon <will@kernel.org>, Ying Huang <ying.huang@intel.com>, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, linux-mm@kvack.org, page-reclaim@google.com, X86 ML <x86@kernel.org> Subject: Re: [PATCH v6 0/9] Multigenerational LRU Framework Date: Tue, 11 Jan 2022 11:40:55 +0100 [thread overview] Message-ID: <Yd1et2VFOX4xxgly@dhcp22.suse.cz> (raw) In-Reply-To: <CAJmaN=n=kn9-gC8if5wp8Gfj7uN+QVrX0ex=9JPXC7rPvGf1Qg@mail.gmail.com> On Mon 10-01-22 14:46:08, Jesse Barnes wrote: > > > > 2. There have been none that came with the testing/benchmarking > > > > coverage as this one did. Please point me to some if I'm mistaken, > > > > and I'll gladly match them. > > > > > > I do appreciate your numbers but you should realize that this is an area > > > that is really hard to get any conclusive testing for. > > > > Fully agreed. That's why we started a new initiative, and we hope more > > people will following these practices: > > 1. All results in this area should be reported with at least standard > > deviations, or preferably confidence intervals. > > 2. Real applications should be benchmarked (with synthetic load > > generator), not just synthetic benchmarks (not real applications). > > 3. A wide range of devices should be covered, i.e., servers, desktops, > > laptops and phones. > > > > I'm very confident to say our benchmark reports were hold to the > > highest standards. We have worked with MariaDB (company), EnterpriseDB > > (Postgres), Redis (company), etc. on these reports. They have copies > > of these reports (PDF version): > > https://linux-mm.googlesource.com/benchmarks/ > > > > We welcome any expert in those applications to examine our reports, > > and we'll be happy to run any other benchmarks or same benchmarks with > > different configurations that anybody thinks it's important and we've > > missed. > > I really think this gets at the heart of the issue with mm > development, and is one of the reasons it's been extra frustrating to > not have an MM conf for the past couple of years; I think sorting out > how we measure & proceed on changes would be easier done f2f. E.g. > concluding with a consensus that if something doesn't regress on X, Y, > and Z, and has reasonably maintainable and readable code, we should > merge it and try it out. I am fully with you on that! I hope we can have LSFMM this year finally. > But since f2f isn't an option until 2052 at the earliest... Let's be more optimistic than that ;) > I understand the desire for an "incremental approach that gets us from > A->B". In the abstract it sounds great. However, with a change like > this one, I think it's highly likely that such a path would be > littered with regressions both large and small, and would probably be > more difficult to reason about than the relatively clean design of > MGLRU. There are certainly things that do not make much sense to split up of course. On the other hand the patchset is making a lot of decisions and assumptions that are neither documented in the code nor in the changelog. From my past experience these are really problematic from a long term maintenance POV. We are struggling with those already because changelog tend to be much more coarse in the past yet the code stays with us and we have been really "great" at not touching many of those because "something might break". This results in the complexity grow and further maintenance burden. > On top of that, I don't think we'll get the kind of user > feedback we need for something like this *without* merging it. Yu has > done a tremendous job collecting data here (and the results are really > incredible), but I think we can all agree that without extensive > testing in the field with all sorts of weird codes, we're not going to > find the problematic behaviors we're concerned about. This is understood. > So unless we want to eschew big mm changes entirely (we shouldn't! > look at net or scheduling for how important big rewrites are to > progress), I think we should be open to experimenting with new stuff. > We can always revert if things get too unwieldy. As long as the patchset doesn't include new user visible interfaces which have proven to be really hard to revert. > None of this is to say that there may not be lots more comments on the > code or potential fixes/changes to incorporate before merging; I'm > mainly arguing about the mindset we should have to changes like this, > not all the stuff the community is already really good at (i.e. > testing and reviewing code on a nuts & bolts level). From my reading of this and previous discussions I have gathered that there was no opposition just for the sake of it. There have been very specific questions regarding the implementation and/or future plans to address issues expressed in the past. So far I have only managed to check the memcg and oom integration finding some issues there. All of them should be fixable reasonably easily but it also points that a deep dive into this is really necessary. I have also raised questions about future maintainability of the resulting code. As you could have noticed the review power in the MM community is lacking behind and we tend to have more code producers than reviewers and maintainers. Not to mention other things like page flags depletion which is something we have been struggling for quite some time already. All that being said there is a lot of work for such a large change to be merged. -- Michal Hocko SUSE Labs _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-01-11 10:41 UTC|newest] Thread overview: 223+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-01-04 20:22 [PATCH v6 0/9] Multigenerational LRU Framework Yu Zhao 2022-01-04 20:22 ` Yu Zhao 2022-01-04 20:22 ` [PATCH v6 1/9] mm: x86, arm64: add arch_has_hw_pte_young() Yu Zhao 2022-01-04 20:22 ` Yu Zhao 2022-01-05 10:45 ` Will Deacon 2022-01-05 10:45 ` Will Deacon 2022-01-05 20:47 ` Yu Zhao 2022-01-05 20:47 ` Yu Zhao 2022-01-06 10:30 ` Will Deacon 2022-01-06 10:30 ` Will Deacon 2022-01-07 7:25 ` Yu Zhao 2022-01-07 7:25 ` Yu Zhao 2022-01-11 14:19 ` Will Deacon 2022-01-11 14:19 ` Will Deacon 2022-01-11 22:27 ` Yu Zhao 2022-01-11 22:27 ` Yu Zhao 2022-01-04 20:22 ` [PATCH v6 2/9] mm: x86: add CONFIG_ARCH_HAS_NONLEAF_PMD_YOUNG Yu Zhao 2022-01-04 20:22 ` Yu Zhao 2022-01-04 21:24 ` Linus Torvalds 2022-01-04 21:24 ` Linus Torvalds 2022-01-04 20:22 ` [PATCH v6 3/9] mm/vmscan.c: refactor shrink_node() Yu Zhao 2022-01-04 20:22 ` Yu Zhao 2022-01-04 20:22 ` [PATCH v6 4/9] mm: multigenerational lru: groundwork Yu Zhao 2022-01-04 20:22 ` Yu Zhao 2022-01-04 21:34 ` Linus Torvalds 2022-01-04 21:34 ` Linus Torvalds 2022-01-11 8:16 ` Aneesh Kumar K.V 2022-01-11 8:16 ` Aneesh Kumar K.V 2022-01-12 2:16 ` Yu Zhao 2022-01-12 2:16 ` Yu Zhao 2022-01-04 20:22 ` [PATCH v6 5/9] mm: multigenerational lru: mm_struct list Yu Zhao 2022-01-04 20:22 ` Yu Zhao 2022-01-07 9:06 ` Michal Hocko 2022-01-07 9:06 ` Michal Hocko 2022-01-08 0:19 ` Yu Zhao 2022-01-08 0:19 ` Yu Zhao 2022-01-10 15:21 ` Michal Hocko 2022-01-10 15:21 ` Michal Hocko 2022-01-12 8:08 ` Yu Zhao 2022-01-12 8:08 ` Yu Zhao 2022-01-04 20:22 ` [PATCH v6 6/9] mm: multigenerational lru: aging Yu Zhao 2022-01-04 20:22 ` Yu Zhao 2022-01-06 16:06 ` Michal Hocko 2022-01-06 16:06 ` Michal Hocko 2022-01-06 21:27 ` Yu Zhao 2022-01-06 21:27 ` Yu Zhao 2022-01-07 8:43 ` Michal Hocko 2022-01-07 8:43 ` Michal Hocko 2022-01-07 21:12 ` Yu Zhao 2022-01-07 21:12 ` Yu Zhao 2022-01-06 16:12 ` Michal Hocko 2022-01-06 16:12 ` Michal Hocko 2022-01-06 21:41 ` Yu Zhao 2022-01-06 21:41 ` Yu Zhao 2022-01-07 8:55 ` Michal Hocko 2022-01-07 8:55 ` Michal Hocko 2022-01-07 9:00 ` Michal Hocko 2022-01-07 9:00 ` Michal Hocko 2022-01-10 3:58 ` Yu Zhao 2022-01-10 3:58 ` Yu Zhao 2022-01-10 14:37 ` Michal Hocko 2022-01-10 14:37 ` Michal Hocko 2022-01-13 9:43 ` Yu Zhao 2022-01-13 9:43 ` Yu Zhao 2022-01-13 12:02 ` Michal Hocko 2022-01-13 12:02 ` Michal Hocko 2022-01-19 6:31 ` Yu Zhao 2022-01-19 6:31 ` Yu Zhao 2022-01-19 9:44 ` Michal Hocko 2022-01-19 9:44 ` Michal Hocko 2022-01-10 15:01 ` Michal Hocko 2022-01-10 15:01 ` Michal Hocko 2022-01-10 16:01 ` Vlastimil Babka 2022-01-10 16:01 ` Vlastimil Babka 2022-01-10 16:25 ` Michal Hocko 2022-01-10 16:25 ` Michal Hocko 2022-01-11 23:16 ` Yu Zhao 2022-01-11 23:16 ` Yu Zhao 2022-01-12 10:28 ` Michal Hocko 2022-01-12 10:28 ` Michal Hocko 2022-01-13 9:25 ` Yu Zhao 2022-01-13 9:25 ` Yu Zhao 2022-01-07 13:11 ` Michal Hocko 2022-01-07 13:11 ` Michal Hocko 2022-01-07 23:36 ` Yu Zhao 2022-01-07 23:36 ` Yu Zhao 2022-01-10 15:35 ` Michal Hocko 2022-01-10 15:35 ` Michal Hocko 2022-01-11 1:18 ` Yu Zhao 2022-01-11 1:18 ` Yu Zhao 2022-01-11 9:00 ` Michal Hocko 2022-01-11 9:00 ` Michal Hocko [not found] ` <1641900108.61dd684cb0e59@mail.inbox.lv> 2022-01-11 12:15 ` Michal Hocko 2022-01-11 12:15 ` Michal Hocko 2022-01-13 17:00 ` Alexey Avramov 2022-01-13 17:00 ` Alexey Avramov 2022-01-11 14:22 ` Alexey Avramov 2022-01-11 14:22 ` Alexey Avramov 2022-01-07 14:44 ` Michal Hocko 2022-01-07 14:44 ` Michal Hocko 2022-01-10 4:47 ` Yu Zhao 2022-01-10 4:47 ` Yu Zhao 2022-01-10 10:54 ` Michal Hocko 2022-01-10 10:54 ` Michal Hocko 2022-01-19 7:04 ` Yu Zhao 2022-01-19 7:04 ` Yu Zhao 2022-01-19 9:42 ` Michal Hocko 2022-01-19 9:42 ` Michal Hocko 2022-01-23 21:28 ` Yu Zhao 2022-01-23 21:28 ` Yu Zhao 2022-01-24 14:01 ` Michal Hocko 2022-01-24 14:01 ` Michal Hocko 2022-01-10 16:57 ` Michal Hocko 2022-01-10 16:57 ` Michal Hocko 2022-01-12 1:01 ` Yu Zhao 2022-01-12 1:01 ` Yu Zhao 2022-01-12 10:17 ` Michal Hocko 2022-01-12 10:17 ` Michal Hocko 2022-01-12 23:43 ` Yu Zhao 2022-01-12 23:43 ` Yu Zhao 2022-01-13 11:57 ` Michal Hocko 2022-01-13 11:57 ` Michal Hocko 2022-01-23 21:40 ` Yu Zhao 2022-01-23 21:40 ` Yu Zhao 2022-01-04 20:22 ` [PATCH v6 7/9] mm: multigenerational lru: eviction Yu Zhao 2022-01-04 20:22 ` Yu Zhao 2022-01-11 10:37 ` Aneesh Kumar K.V 2022-01-11 10:37 ` Aneesh Kumar K.V 2022-01-12 8:05 ` Yu Zhao 2022-01-12 8:05 ` Yu Zhao 2022-01-04 20:22 ` [PATCH v6 8/9] mm: multigenerational lru: user interface Yu Zhao 2022-01-04 20:22 ` Yu Zhao 2022-01-10 10:27 ` Mike Rapoport 2022-01-10 10:27 ` Mike Rapoport 2022-01-12 8:35 ` Yu Zhao 2022-01-12 8:35 ` Yu Zhao 2022-01-12 10:31 ` Michal Hocko 2022-01-12 10:31 ` Michal Hocko 2022-01-12 15:45 ` Mike Rapoport 2022-01-12 15:45 ` Mike Rapoport 2022-01-13 9:47 ` Yu Zhao 2022-01-13 9:47 ` Yu Zhao 2022-01-13 10:31 ` Aneesh Kumar K.V 2022-01-13 10:31 ` Aneesh Kumar K.V 2022-01-13 23:02 ` Yu Zhao 2022-01-13 23:02 ` Yu Zhao 2022-01-14 5:20 ` Aneesh Kumar K.V 2022-01-14 5:20 ` Aneesh Kumar K.V 2022-01-14 6:50 ` Yu Zhao 2022-01-14 6:50 ` Yu Zhao 2022-01-04 20:22 ` [PATCH v6 9/9] mm: multigenerational lru: Kconfig Yu Zhao 2022-01-04 20:22 ` Yu Zhao 2022-01-04 21:39 ` Linus Torvalds 2022-01-04 21:39 ` Linus Torvalds 2022-01-04 20:22 ` [PATCH v6 0/9] Multigenerational LRU Framework Yu Zhao 2022-01-04 20:30 ` Yu Zhao 2022-01-04 20:30 ` Yu Zhao 2022-01-04 21:43 ` Linus Torvalds 2022-01-04 21:43 ` Linus Torvalds 2022-01-05 21:12 ` Yu Zhao 2022-01-05 21:12 ` Yu Zhao 2022-01-07 9:38 ` Michal Hocko 2022-01-07 9:38 ` Michal Hocko 2022-01-07 18:45 ` Yu Zhao 2022-01-07 18:45 ` Yu Zhao 2022-01-10 15:39 ` Michal Hocko 2022-01-10 15:39 ` Michal Hocko 2022-01-10 22:04 ` Yu Zhao 2022-01-10 22:04 ` Yu Zhao 2022-01-10 22:46 ` Jesse Barnes 2022-01-10 22:46 ` Jesse Barnes 2022-01-11 1:41 ` Linus Torvalds 2022-01-11 1:41 ` Linus Torvalds 2022-01-11 10:40 ` Michal Hocko [this message] 2022-01-11 10:40 ` Michal Hocko 2022-01-11 8:41 ` Yu Zhao 2022-01-11 8:41 ` Yu Zhao 2022-01-11 8:53 ` Holger Hoffstätte 2022-01-11 8:53 ` Holger Hoffstätte 2022-01-11 9:26 ` Jan Alexander Steffens (heftig) 2022-01-11 16:04 ` Shuang Zhai 2022-01-11 16:04 ` Shuang Zhai 2022-01-12 1:46 ` Suleiman Souhlal 2022-01-12 1:46 ` Suleiman Souhlal 2022-01-12 6:07 ` Sofia Trinh 2022-01-12 6:07 ` Sofia Trinh 2022-01-12 16:17 ` Daniel Byrne 2022-01-18 9:21 ` Yu Zhao 2022-01-18 9:21 ` Yu Zhao 2022-01-18 9:36 ` Donald Carr 2022-01-18 9:36 ` Donald Carr 2022-01-19 20:19 ` Steven Barrett 2022-01-19 20:19 ` Steven Barrett 2022-01-19 22:25 ` Brian Geffon 2022-01-19 22:25 ` Brian Geffon 2022-01-05 2:44 ` Shuang Zhai 2022-01-05 2:44 ` Shuang Zhai 2022-01-05 8:55 ` SeongJae Park 2022-01-05 8:55 ` SeongJae Park 2022-01-05 10:53 ` Yu Zhao 2022-01-05 10:53 ` Yu Zhao 2022-01-05 11:12 ` Borislav Petkov 2022-01-05 11:12 ` Borislav Petkov 2022-01-05 11:25 ` SeongJae Park 2022-01-05 11:25 ` SeongJae Park 2022-01-05 21:06 ` Yu Zhao 2022-01-05 21:06 ` Yu Zhao 2022-01-10 14:49 ` Alexey Avramov 2022-01-10 14:49 ` Alexey Avramov 2022-01-11 10:24 ` Alexey Avramov 2022-01-11 10:24 ` Alexey Avramov 2022-01-12 20:56 ` Oleksandr Natalenko 2022-01-12 20:56 ` Oleksandr Natalenko 2022-01-13 8:59 ` Yu Zhao 2022-01-13 8:59 ` Yu Zhao 2022-01-23 5:43 ` Barry Song 2022-01-23 5:43 ` Barry Song 2022-01-25 6:48 ` Yu Zhao 2022-01-25 6:48 ` Yu Zhao 2022-01-28 8:54 ` Barry Song 2022-01-28 8:54 ` Barry Song 2022-02-08 9:16 ` Yu Zhao 2022-02-08 9:16 ` Yu Zhao
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=Yd1et2VFOX4xxgly@dhcp22.suse.cz \ --to=mhocko@suse.com \ --cc=Michael@michaellarabel.com \ --cc=ak@linux.intel.com \ --cc=akpm@linux-foundation.org \ --cc=axboe@kernel.dk \ --cc=catalin.marinas@arm.com \ --cc=corbet@lwn.net \ --cc=dave.hansen@linux.intel.com \ --cc=hannes@cmpxchg.org \ --cc=hdanton@sina.com \ --cc=jsbarnes@google.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mgorman@suse.de \ --cc=page-reclaim@google.com \ --cc=riel@surriel.com \ --cc=torvalds@linux-foundation.org \ --cc=vbabka@suse.cz \ --cc=will@kernel.org \ --cc=willy@infradead.org \ --cc=x86@kernel.org \ --cc=ying.huang@intel.com \ --cc=yuzhao@google.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.