From: Lennart Poettering <mzxreary@0pointer.de> To: Tejun Heo <tj@kernel.org> Cc: Li Zefan <lizf@cn.fujitsu.com>, containers@lists.linux-foundation.org, cgroups@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>, Kay Sievers <kay.sievers@vrfy.org>, Frederic Weisbecker <fweisbec@gmail.com>, linux-kernel@vger.kernel.org Subject: Re: [RFD] cgroup: about multiple hierarchies Date: Mon, 5 Mar 2012 12:37:30 +0100 [thread overview] Message-ID: <20120305113730.GC10929@tango.0pointer.de> (raw) In-Reply-To: <20120221211938.GE12236@google.com> On Tue, 21.02.12 13:19, Tejun Heo (tj@kernel.org) wrote: > Hello, guys. Heya, > I've been thinking about multiple hierarchy support in cgroup for a > while, especially after Frederic's pending task counter patchset. > This is a write up of what I've been thinking. I don't know what to > do yet and simply continuing the current situation definitely is an > option, so please read on and throw in your 20 Won (or whatever amount > in whatever currency you want). Sorry for responding to this thread only this late, but here are my 2 eurocents on this. Yes, I think it would make a ton of sense simplifiying the cgroup logic drastically. I see no need to maintain a number of entirely orthogonal hierarchies in parallel. That said, I think that allowing some kind of deviation from the main cgroup tree for some controlls might be a good idea, however. More specifically, even if a task is placed in some specific cgroup down the tree it might make sense for some controllers to consider it in the root cgroup. e.g. since some controllers are more expensive than others it might make sense to leave task A in /foobar/waldo for the memory controller, but in / for the block IO controller. But placing A in /foobar/waldo for the memory controller and in /piep/papo makes little sense, if you understand what I mean. To implement something like this it might be enough to enforce a single hierarchy only but then allow tasks to either live in the tree or live outside the tree for a specific controller, and that's it. > Heh, I don't know. IIRC, last year at LinuxCon Japan, I heard > Christoph saying that the biggest problem w/ cgroup was that it was > building completely separate hierarchies out of the traditional > process hierarchies. After thinking about this stuff for a while, I > fully agree with him. I think this whole thing should have been a > layer over the process tree like sessions or program groups. Hmm, so while in general I think I agree with this sentiment, I am not entirely sure. For example, on systemd systems we currently set up one cgroup per user (/user/lennart/), and in that cgroup a cgroup per session (/user/lennart/4711/). This implies that when the same user logs in twice his processes will be placed beneath the same parent cgroup (/user/lennart/), which I kinda read would be conflicting with what you suggest, no? > This path would require the most amount of work and we would be > excluding a feature - support for multiple orthogonal > categorizations - which has been available till now, probably > through deprecation process spanning years; however, this at least > gives us hope that we may reach sanity in the end, how distant that > end may be. Oh, hope. :) > > So, I mean, I don't know. What do other people think? Is this a > unnecessary worry? Are people generally happy with the way things > are? Lennart, Kay, what do you guys think? A clean-up like you suggest as 3, is something we'd be happy to support. I am happy to make any change necessary to adapt systemd to whatever makes sense in the kernel. To me the current flexibility of the cgroup interface appears way over-the-top, and a much simpler design would suffice too and be more understandable to the user. (starting from the fact that ps output currently looks really awful, since it lists cgroup membership for all hierarchies, which just looks crazy) Lennart -- Lennart Poettering - Red Hat, Inc.
WARNING: multiple messages have this Message-ID (diff)
From: Lennart Poettering <mzxreary-uLTowLwuiw4b1SvskN2V4Q@public.gmane.org> To: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> Cc: Li Zefan <lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>, containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>, Kay Sievers <kay.sievers-tD+1rO4QERM@public.gmane.org>, Frederic Weisbecker <fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Subject: Re: [RFD] cgroup: about multiple hierarchies Date: Mon, 5 Mar 2012 12:37:30 +0100 [thread overview] Message-ID: <20120305113730.GC10929@tango.0pointer.de> (raw) In-Reply-To: <20120221211938.GE12236-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> On Tue, 21.02.12 13:19, Tejun Heo (tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org) wrote: > Hello, guys. Heya, > I've been thinking about multiple hierarchy support in cgroup for a > while, especially after Frederic's pending task counter patchset. > This is a write up of what I've been thinking. I don't know what to > do yet and simply continuing the current situation definitely is an > option, so please read on and throw in your 20 Won (or whatever amount > in whatever currency you want). Sorry for responding to this thread only this late, but here are my 2 eurocents on this. Yes, I think it would make a ton of sense simplifiying the cgroup logic drastically. I see no need to maintain a number of entirely orthogonal hierarchies in parallel. That said, I think that allowing some kind of deviation from the main cgroup tree for some controlls might be a good idea, however. More specifically, even if a task is placed in some specific cgroup down the tree it might make sense for some controllers to consider it in the root cgroup. e.g. since some controllers are more expensive than others it might make sense to leave task A in /foobar/waldo for the memory controller, but in / for the block IO controller. But placing A in /foobar/waldo for the memory controller and in /piep/papo makes little sense, if you understand what I mean. To implement something like this it might be enough to enforce a single hierarchy only but then allow tasks to either live in the tree or live outside the tree for a specific controller, and that's it. > Heh, I don't know. IIRC, last year at LinuxCon Japan, I heard > Christoph saying that the biggest problem w/ cgroup was that it was > building completely separate hierarchies out of the traditional > process hierarchies. After thinking about this stuff for a while, I > fully agree with him. I think this whole thing should have been a > layer over the process tree like sessions or program groups. Hmm, so while in general I think I agree with this sentiment, I am not entirely sure. For example, on systemd systems we currently set up one cgroup per user (/user/lennart/), and in that cgroup a cgroup per session (/user/lennart/4711/). This implies that when the same user logs in twice his processes will be placed beneath the same parent cgroup (/user/lennart/), which I kinda read would be conflicting with what you suggest, no? > This path would require the most amount of work and we would be > excluding a feature - support for multiple orthogonal > categorizations - which has been available till now, probably > through deprecation process spanning years; however, this at least > gives us hope that we may reach sanity in the end, how distant that > end may be. Oh, hope. :) > > So, I mean, I don't know. What do other people think? Is this a > unnecessary worry? Are people generally happy with the way things > are? Lennart, Kay, what do you guys think? A clean-up like you suggest as 3, is something we'd be happy to support. I am happy to make any change necessary to adapt systemd to whatever makes sense in the kernel. To me the current flexibility of the cgroup interface appears way over-the-top, and a much simpler design would suffice too and be more understandable to the user. (starting from the fact that ps output currently looks really awful, since it lists cgroup membership for all hierarchies, which just looks crazy) Lennart -- Lennart Poettering - Red Hat, Inc.
next prev parent reply other threads:[~2012-03-05 11:37 UTC|newest] Thread overview: 211+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-02-21 21:19 [RFD] cgroup: about multiple hierarchies Tejun Heo 2012-02-21 21:19 ` Tejun Heo 2012-02-21 21:21 ` Tejun Heo 2012-02-21 21:21 ` Tejun Heo 2012-02-22 13:34 ` Glauber Costa 2012-02-22 13:34 ` Glauber Costa 2012-02-23 7:45 ` Serge E. Hallyn 2012-02-23 7:45 ` Serge E. Hallyn [not found] ` <20120223074526.GA15835-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org> 2012-02-23 17:29 ` Tejun Heo 2012-02-23 17:29 ` Tejun Heo [not found] ` <20120223172915.GC22536-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> 2012-02-23 18:47 ` Serge Hallyn 2012-02-23 18:47 ` Serge Hallyn [not found] ` <4F44EEE4.2000809-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> 2012-02-23 7:45 ` Serge E. Hallyn 2012-02-26 4:59 ` Konstantin Khlebnikov 2012-02-26 4:59 ` Konstantin Khlebnikov [not found] ` <20120221212106.GF12236-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> 2012-02-22 13:34 ` Glauber Costa 2012-02-26 4:59 ` Konstantin Khlebnikov 2012-02-22 13:30 ` Peter Zijlstra 2012-02-22 13:30 ` Peter Zijlstra 2012-02-22 13:37 ` Glauber Costa 2012-02-22 13:37 ` Glauber Costa 2012-02-22 13:37 ` Glauber Costa 2012-02-22 18:01 ` Tejun Heo 2012-02-22 18:01 ` Tejun Heo 2012-02-22 18:01 ` Tejun Heo 2012-02-23 7:39 ` Li Zefan 2012-02-23 7:39 ` Li Zefan 2012-02-23 7:39 ` Li Zefan 2012-02-22 16:38 ` Vivek Goyal 2012-02-22 16:38 ` Vivek Goyal 2012-02-22 16:57 ` Vivek Goyal 2012-02-22 16:57 ` Vivek Goyal 2012-02-22 18:43 ` Tejun Heo 2012-02-22 18:43 ` Tejun Heo [not found] ` <20120222165714.GC4128-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2012-02-22 18:43 ` Tejun Heo 2012-02-23 9:41 ` Peter Zijlstra 2012-02-23 9:41 ` Peter Zijlstra 2012-02-23 14:13 ` Peter Zijlstra 2012-02-23 14:13 ` Peter Zijlstra 2012-03-01 17:19 ` Michal Schmidt 2012-03-01 17:19 ` Michal Schmidt [not found] ` <4F4FAF89.3090706-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2012-03-01 18:03 ` Peter Zijlstra 2012-03-01 18:03 ` Peter Zijlstra 2012-03-02 11:08 ` Michal Schmidt 2012-03-02 11:08 ` Michal Schmidt [not found] ` <4F50AA22.9080007-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2012-03-02 11:23 ` Peter Zijlstra 2012-03-02 11:23 ` Peter Zijlstra 2012-03-02 11:23 ` Peter Zijlstra 2012-03-02 11:28 ` Michal Schmidt 2012-03-02 11:28 ` Michal Schmidt [not found] ` <4F50AEC3.5090807-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2012-03-02 11:34 ` Peter Zijlstra 2012-03-02 11:34 ` Peter Zijlstra 2012-03-01 20:26 ` Mike Galbraith 2012-03-01 20:26 ` Mike Galbraith 2012-03-01 20:26 ` Mike Galbraith 2012-03-01 21:02 ` Vivek Goyal 2012-03-01 21:02 ` Vivek Goyal [not found] ` <20120301210213.GF13533-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2012-03-01 22:04 ` Mike Galbraith 2012-03-01 22:04 ` Mike Galbraith 2012-03-01 22:04 ` Mike Galbraith 2012-03-01 22:38 ` C Anthony Risinger 2012-03-01 22:38 ` C Anthony Risinger [not found] ` <1330639448.7414.97.camel-YqMYhexLQo31wTEvPJ5Q0F6hYfS7NtTn@public.gmane.org> 2012-03-01 22:38 ` C Anthony Risinger 2012-03-02 10:51 ` Michal Schmidt 2012-03-02 10:51 ` Michal Schmidt 2012-03-02 11:52 ` Mike Galbraith 2012-03-02 11:52 ` Mike Galbraith [not found] ` <4F50A63F.40306-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2012-03-02 11:52 ` Mike Galbraith 2012-03-05 12:43 ` Lennart Poettering 2012-03-05 12:43 ` Lennart Poettering 2012-03-05 15:47 ` Mike Galbraith 2012-03-05 15:47 ` Mike Galbraith [not found] ` <1330962421.7368.69.camel-YqMYhexLQo31wTEvPJ5Q0F6hYfS7NtTn@public.gmane.org> 2012-03-05 19:58 ` Mike Galbraith 2012-03-05 19:58 ` Mike Galbraith [not found] ` <20120305124310.GD10929-kS5D54t9nk0aINubkmmoJbNAH6kLmebB@public.gmane.org> 2012-03-05 15:47 ` Mike Galbraith [not found] ` <1330633603.7414.49.camel-YqMYhexLQo31wTEvPJ5Q0F6hYfS7NtTn@public.gmane.org> 2012-03-01 21:02 ` Vivek Goyal 2012-03-02 2:43 ` Kay Sievers 2012-03-02 2:43 ` Kay Sievers 2012-03-02 10:15 ` Peter Zijlstra 2012-03-02 10:15 ` Peter Zijlstra [not found] ` <CAPXgP12_A=uz_p92eBN49DTSKj7iP0rChW9cE81aZKWEjOH5nA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2012-03-02 10:15 ` Peter Zijlstra 2012-03-02 11:16 ` Michal Schmidt 2012-03-02 11:16 ` Michal Schmidt [not found] ` <4F50ABF2.5070809-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2012-03-02 11:24 ` Peter Zijlstra 2012-03-02 11:24 ` Peter Zijlstra 2012-03-02 11:24 ` Peter Zijlstra 2012-02-23 21:38 ` Vivek Goyal 2012-02-23 21:38 ` Vivek Goyal [not found] ` <20120223213847.GK19691-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2012-02-23 22:34 ` Tejun Heo 2012-02-23 22:34 ` Tejun Heo [not found] ` <20120223223457.GJ22536-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> 2012-02-28 21:16 ` Vivek Goyal 2012-02-28 21:16 ` Vivek Goyal [not found] ` <20120228211627.GH9920-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2012-02-28 21:21 ` Peter Zijlstra 2012-02-28 21:21 ` Peter Zijlstra 2012-02-28 21:35 ` Vivek Goyal 2012-02-28 21:35 ` Vivek Goyal [not found] ` <20120228213526.GI9920-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2012-02-28 21:43 ` Peter Zijlstra 2012-02-28 21:43 ` Peter Zijlstra 2012-02-28 21:54 ` Vivek Goyal 2012-02-28 21:54 ` Vivek Goyal [not found] ` <20120228215439.GJ9920-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2012-02-28 22:00 ` Peter Zijlstra 2012-02-28 22:00 ` Peter Zijlstra 2012-02-28 22:31 ` Vivek Goyal 2012-02-28 22:31 ` Vivek Goyal 2012-02-28 21:53 ` Peter Zijlstra 2012-02-28 21:53 ` Peter Zijlstra 2012-02-28 22:09 ` Vivek Goyal 2012-02-28 22:09 ` Vivek Goyal 2012-02-24 11:33 ` Peter Zijlstra 2012-02-24 11:33 ` Peter Zijlstra 2012-02-22 18:33 ` Tejun Heo 2012-02-22 18:33 ` Tejun Heo [not found] ` <20120222183351.GD32694-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> 2012-02-23 19:41 ` Vivek Goyal 2012-02-23 19:41 ` Vivek Goyal [not found] ` <20120223194109.GI19691-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2012-02-23 22:38 ` Tejun Heo 2012-02-23 22:38 ` Tejun Heo 2012-02-23 22:38 ` Tejun Heo 2012-02-23 7:59 ` Li Zefan 2012-02-23 7:59 ` Li Zefan [not found] ` <4F45F1F0.2010102-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org> 2012-02-23 20:32 ` Vivek Goyal 2012-02-23 20:32 ` Vivek Goyal [not found] ` <20120222163858.GB4128-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2012-02-22 16:57 ` Vivek Goyal 2012-02-22 18:33 ` Tejun Heo 2012-02-23 7:59 ` Li Zefan 2012-02-23 8:22 ` Li Zefan 2012-02-23 8:22 ` Li Zefan 2012-02-23 17:33 ` Tejun Heo 2012-02-23 17:33 ` Tejun Heo [not found] ` <4F45F742.1060605-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org> 2012-02-23 17:33 ` Tejun Heo 2012-03-05 11:37 ` Lennart Poettering [this message] 2012-03-05 11:37 ` Lennart Poettering [not found] ` <20120221211938.GE12236-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> 2012-02-21 21:21 ` Tejun Heo 2012-02-22 13:30 ` Peter Zijlstra 2012-02-22 15:45 ` Frederic Weisbecker 2012-02-22 15:45 ` Frederic Weisbecker [not found] ` <20120222154501.GA1693-oHC15RC7JGTpAmv0O++HtFaTQe2KTcn/@public.gmane.org> 2012-02-22 18:22 ` Tejun Heo 2012-02-22 18:22 ` Tejun Heo 2012-02-22 18:22 ` Tejun Heo 2012-02-27 17:46 ` Frederic Weisbecker [not found] ` <20120222182207.GC32694-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> 2012-02-27 17:46 ` Frederic Weisbecker 2012-02-22 16:38 ` Vivek Goyal 2012-02-23 8:22 ` Li Zefan 2012-03-03 9:58 ` Eric W. Biederman 2012-03-03 14:26 ` Serge Hallyn 2012-03-03 14:26 ` Serge Hallyn [not found] ` <m162em2efy.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org> 2012-03-03 14:26 ` Serge Hallyn 2012-03-05 11:37 ` Lennart Poettering 2012-03-12 22:10 ` Tejun Heo 2012-03-12 22:10 ` Tejun Heo 2012-03-12 22:10 ` Tejun Heo 2012-03-12 22:22 ` Peter Zijlstra 2012-03-12 22:22 ` Peter Zijlstra 2012-03-12 22:28 ` Tejun Heo 2012-03-12 22:28 ` Tejun Heo 2012-03-12 22:31 ` Lennart Poettering 2012-03-12 22:31 ` Lennart Poettering 2012-03-12 23:00 ` Tejun Heo 2012-03-12 23:00 ` Tejun Heo [not found] ` <20120312230020.GL23255-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> 2012-03-12 23:02 ` Peter Zijlstra 2012-03-12 23:02 ` Peter Zijlstra 2012-03-12 23:09 ` Tejun Heo 2012-03-12 23:09 ` Tejun Heo 2012-03-12 23:09 ` Tejun Heo 2012-03-12 23:43 ` Lennart Poettering 2012-03-12 23:43 ` Lennart Poettering [not found] ` <20120312223113.GB18359-kS5D54t9nk0aINubkmmoJbNAH6kLmebB@public.gmane.org> 2012-03-12 23:00 ` Tejun Heo [not found] ` <20120312222817.GI23255-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> 2012-03-12 22:31 ` Lennart Poettering 2012-03-12 22:32 ` Peter Zijlstra 2012-03-12 22:32 ` Peter Zijlstra 2012-03-12 22:39 ` Tejun Heo 2012-03-12 22:39 ` Tejun Heo [not found] ` <20120312223944.GJ23255-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> 2012-03-12 22:44 ` Peter Zijlstra 2012-03-12 22:44 ` Peter Zijlstra 2012-03-12 23:04 ` Tejun Heo 2012-03-12 23:04 ` Tejun Heo [not found] ` <20120312230416.GM23255-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> 2012-03-13 14:10 ` Vivek Goyal 2012-03-13 14:10 ` Vivek Goyal 2012-03-13 16:11 ` C Anthony Risinger 2012-03-13 16:11 ` C Anthony Risinger [not found] ` <CAGAVQTGus7LUWV3AdhAFy--gr=uJRWtSGjuP69-EckBiXy0qVg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2012-03-13 16:30 ` C Anthony Risinger 2012-03-13 16:30 ` C Anthony Risinger [not found] ` <20120313141032.GD29169-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2012-03-13 16:11 ` C Anthony Risinger 2012-03-13 17:25 ` Peter Zijlstra 2012-03-13 17:25 ` Peter Zijlstra 2012-03-13 17:31 ` Peter Zijlstra 2012-03-13 17:31 ` Peter Zijlstra 2012-03-13 10:11 ` Glauber Costa 2012-03-13 10:11 ` Glauber Costa 2012-03-13 10:11 ` Glauber Costa 2012-03-12 22:39 ` Tejun Heo 2012-03-13 14:03 ` Vivek Goyal 2012-03-13 14:03 ` Vivek Goyal 2012-03-13 15:59 ` Tejun Heo 2012-03-13 15:59 ` Tejun Heo 2012-03-16 23:14 ` James Bottomley 2012-03-16 23:14 ` James Bottomley [not found] ` <20120313155955.GB7349-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> 2012-03-16 23:14 ` James Bottomley [not found] ` <20120313140345.GC29169-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2012-03-13 15:59 ` Tejun Heo [not found] ` <20120312221050.GG23255-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> 2012-03-12 22:22 ` Peter Zijlstra 2012-03-12 22:37 ` Serge Hallyn 2012-03-13 13:49 ` Vivek Goyal 2012-03-13 13:49 ` Vivek Goyal [not found] ` <20120313134922.GB29169-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2012-03-13 16:02 ` Tejun Heo 2012-03-13 16:02 ` Tejun Heo 2012-03-13 16:02 ` Tejun Heo 2012-03-12 22:37 ` Serge Hallyn 2012-03-12 22:37 ` Serge Hallyn 2012-03-12 22:55 ` Tejun Heo 2012-03-12 22:55 ` Tejun Heo 2012-03-12 22:55 ` Tejun Heo -- strict thread matches above, loose matches on Subject: below -- 2012-02-21 21:19 Tejun Heo
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=20120305113730.GC10929@tango.0pointer.de \ --to=mzxreary@0pointer.de \ --cc=akpm@linux-foundation.org \ --cc=cgroups@vger.kernel.org \ --cc=containers@lists.linux-foundation.org \ --cc=fweisbec@gmail.com \ --cc=kay.sievers@vrfy.org \ --cc=linux-kernel@vger.kernel.org \ --cc=lizf@cn.fujitsu.com \ --cc=tj@kernel.org \ /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.