From: "Christian König" <christian.koenig@amd.com>
To: "Michal Hocko" <mhocko@suse.com>,
"Christian König" <ckoenig.leichtzumerken@gmail.com>
Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
intel-gfx@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
nouveau@lists.freedesktop.org, linux-tegra@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
alexander.deucher@amd.com, daniel@ffwll.ch,
viro@zeniv.linux.org.uk, akpm@linux-foundation.org,
hughd@google.com, andrey.grodzovsky@amd.com
Subject: Re: [PATCH 03/13] mm: shmem: provide oom badness for shmem files
Date: Thu, 9 Jun 2022 16:29:46 +0200 [thread overview]
Message-ID: <d4a19481-7a9f-19bf-c270-d89baa0970fc@amd.com> (raw)
In-Reply-To: <YqIB0bavUeU8Abwl@dhcp22.suse.cz>
Am 09.06.22 um 16:21 schrieb Michal Hocko:
> On Thu 09-06-22 16:10:33, Christian König wrote:
>> Am 09.06.22 um 14:57 schrieb Michal Hocko:
>>> On Thu 09-06-22 14:16:56, Christian König wrote:
>>>> Am 09.06.22 um 11:18 schrieb Michal Hocko:
>>>>> On Tue 31-05-22 11:59:57, Christian König wrote:
>>>>>> This gives the OOM killer an additional hint which processes are
>>>>>> referencing shmem files with potentially no other accounting for them.
>>>>>>
>>>>>> Signed-off-by: Christian König <christian.koenig@amd.com>
>>>>>> ---
>>>>>> mm/shmem.c | 6 ++++++
>>>>>> 1 file changed, 6 insertions(+)
>>>>>>
>>>>>> diff --git a/mm/shmem.c b/mm/shmem.c
>>>>>> index 4b2fea33158e..a4ad92a16968 100644
>>>>>> --- a/mm/shmem.c
>>>>>> +++ b/mm/shmem.c
>>>>>> @@ -2179,6 +2179,11 @@ unsigned long shmem_get_unmapped_area(struct file *file,
>>>>>> return inflated_addr;
>>>>>> }
>>>>>> +static long shmem_oom_badness(struct file *file)
>>>>>> +{
>>>>>> + return i_size_read(file_inode(file)) >> PAGE_SHIFT;
>>>>>> +}
>>>>> This doesn't really represent the in memory size of the file, does it?
>>>> Well the file could be partially or fully swapped out as anonymous memory or
>>>> the address space only sparse populated, but even then just using the file
>>>> size as OOM badness sounded like the most straightforward approach to me.
>>> It covers hole as well, right?
>> Yes, exactly.
> So let's say I have a huge sparse shmem file. I will get killed because
> the oom_badness of such a file would be large as well...
Yes, correct. But I of hand don't see how we could improve that accounting.
>>>> What could happen is that the file is also mmaped and we double account.
>>>>
>>>>> Also the memcg oom handling could be considerably skewed if the file was
>>>>> shared between more memcgs.
>>>> Yes, and that's one of the reasons why I didn't touched the memcg by this
>>>> and only affected the classic OOM killer.
>>> oom_badness is for all oom handlers, including memcg. Maybe I have
>>> misread an earlier patch but I do not see anything specific to global
>>> oom handling.
>> As far as I can see the oom_badness() function is only used in
>> oom_kill.c and in procfs to return the oom score. Did I missed
>> something?
> oom_kill.c implements most of the oom killer functionality. Memcg oom
> killing is a part of that. Have a look at select_bad_process.
Ah! So mem_cgroup_scan_tasks() calls oom_evaluate_task for each task in
the control group.
Thanks for pointing that out, that was absolutely not obvious to me.
Is that a show stopper? How should we address this?
Christian.
WARNING: multiple messages have this Message-ID (diff)
From: "Christian König" <christian.koenig@amd.com>
To: "Michal Hocko" <mhocko@suse.com>,
"Christian König" <ckoenig.leichtzumerken@gmail.com>
Cc: andrey.grodzovsky@amd.com, linux-mm@kvack.org,
nouveau@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
hughd@google.com, linux-kernel@vger.kernel.org,
amd-gfx@lists.freedesktop.org, linux-fsdevel@vger.kernel.org,
viro@zeniv.linux.org.uk, daniel@ffwll.ch,
linux-tegra@vger.kernel.org, alexander.deucher@amd.com,
akpm@linux-foundation.org, linux-media@vger.kernel.org
Subject: Re: [Nouveau] [PATCH 03/13] mm: shmem: provide oom badness for shmem files
Date: Thu, 9 Jun 2022 16:29:46 +0200 [thread overview]
Message-ID: <d4a19481-7a9f-19bf-c270-d89baa0970fc@amd.com> (raw)
In-Reply-To: <YqIB0bavUeU8Abwl@dhcp22.suse.cz>
Am 09.06.22 um 16:21 schrieb Michal Hocko:
> On Thu 09-06-22 16:10:33, Christian König wrote:
>> Am 09.06.22 um 14:57 schrieb Michal Hocko:
>>> On Thu 09-06-22 14:16:56, Christian König wrote:
>>>> Am 09.06.22 um 11:18 schrieb Michal Hocko:
>>>>> On Tue 31-05-22 11:59:57, Christian König wrote:
>>>>>> This gives the OOM killer an additional hint which processes are
>>>>>> referencing shmem files with potentially no other accounting for them.
>>>>>>
>>>>>> Signed-off-by: Christian König <christian.koenig@amd.com>
>>>>>> ---
>>>>>> mm/shmem.c | 6 ++++++
>>>>>> 1 file changed, 6 insertions(+)
>>>>>>
>>>>>> diff --git a/mm/shmem.c b/mm/shmem.c
>>>>>> index 4b2fea33158e..a4ad92a16968 100644
>>>>>> --- a/mm/shmem.c
>>>>>> +++ b/mm/shmem.c
>>>>>> @@ -2179,6 +2179,11 @@ unsigned long shmem_get_unmapped_area(struct file *file,
>>>>>> return inflated_addr;
>>>>>> }
>>>>>> +static long shmem_oom_badness(struct file *file)
>>>>>> +{
>>>>>> + return i_size_read(file_inode(file)) >> PAGE_SHIFT;
>>>>>> +}
>>>>> This doesn't really represent the in memory size of the file, does it?
>>>> Well the file could be partially or fully swapped out as anonymous memory or
>>>> the address space only sparse populated, but even then just using the file
>>>> size as OOM badness sounded like the most straightforward approach to me.
>>> It covers hole as well, right?
>> Yes, exactly.
> So let's say I have a huge sparse shmem file. I will get killed because
> the oom_badness of such a file would be large as well...
Yes, correct. But I of hand don't see how we could improve that accounting.
>>>> What could happen is that the file is also mmaped and we double account.
>>>>
>>>>> Also the memcg oom handling could be considerably skewed if the file was
>>>>> shared between more memcgs.
>>>> Yes, and that's one of the reasons why I didn't touched the memcg by this
>>>> and only affected the classic OOM killer.
>>> oom_badness is for all oom handlers, including memcg. Maybe I have
>>> misread an earlier patch but I do not see anything specific to global
>>> oom handling.
>> As far as I can see the oom_badness() function is only used in
>> oom_kill.c and in procfs to return the oom score. Did I missed
>> something?
> oom_kill.c implements most of the oom killer functionality. Memcg oom
> killing is a part of that. Have a look at select_bad_process.
Ah! So mem_cgroup_scan_tasks() calls oom_evaluate_task for each task in
the control group.
Thanks for pointing that out, that was absolutely not obvious to me.
Is that a show stopper? How should we address this?
Christian.
WARNING: multiple messages have this Message-ID (diff)
From: "Christian König" <christian.koenig@amd.com>
To: "Michal Hocko" <mhocko@suse.com>,
"Christian König" <ckoenig.leichtzumerken@gmail.com>
Cc: andrey.grodzovsky@amd.com, linux-mm@kvack.org,
nouveau@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
hughd@google.com, linux-kernel@vger.kernel.org,
amd-gfx@lists.freedesktop.org, linux-fsdevel@vger.kernel.org,
viro@zeniv.linux.org.uk, linux-tegra@vger.kernel.org,
alexander.deucher@amd.com, akpm@linux-foundation.org,
linux-media@vger.kernel.org
Subject: Re: [Intel-gfx] [PATCH 03/13] mm: shmem: provide oom badness for shmem files
Date: Thu, 9 Jun 2022 16:29:46 +0200 [thread overview]
Message-ID: <d4a19481-7a9f-19bf-c270-d89baa0970fc@amd.com> (raw)
In-Reply-To: <YqIB0bavUeU8Abwl@dhcp22.suse.cz>
Am 09.06.22 um 16:21 schrieb Michal Hocko:
> On Thu 09-06-22 16:10:33, Christian König wrote:
>> Am 09.06.22 um 14:57 schrieb Michal Hocko:
>>> On Thu 09-06-22 14:16:56, Christian König wrote:
>>>> Am 09.06.22 um 11:18 schrieb Michal Hocko:
>>>>> On Tue 31-05-22 11:59:57, Christian König wrote:
>>>>>> This gives the OOM killer an additional hint which processes are
>>>>>> referencing shmem files with potentially no other accounting for them.
>>>>>>
>>>>>> Signed-off-by: Christian König <christian.koenig@amd.com>
>>>>>> ---
>>>>>> mm/shmem.c | 6 ++++++
>>>>>> 1 file changed, 6 insertions(+)
>>>>>>
>>>>>> diff --git a/mm/shmem.c b/mm/shmem.c
>>>>>> index 4b2fea33158e..a4ad92a16968 100644
>>>>>> --- a/mm/shmem.c
>>>>>> +++ b/mm/shmem.c
>>>>>> @@ -2179,6 +2179,11 @@ unsigned long shmem_get_unmapped_area(struct file *file,
>>>>>> return inflated_addr;
>>>>>> }
>>>>>> +static long shmem_oom_badness(struct file *file)
>>>>>> +{
>>>>>> + return i_size_read(file_inode(file)) >> PAGE_SHIFT;
>>>>>> +}
>>>>> This doesn't really represent the in memory size of the file, does it?
>>>> Well the file could be partially or fully swapped out as anonymous memory or
>>>> the address space only sparse populated, but even then just using the file
>>>> size as OOM badness sounded like the most straightforward approach to me.
>>> It covers hole as well, right?
>> Yes, exactly.
> So let's say I have a huge sparse shmem file. I will get killed because
> the oom_badness of such a file would be large as well...
Yes, correct. But I of hand don't see how we could improve that accounting.
>>>> What could happen is that the file is also mmaped and we double account.
>>>>
>>>>> Also the memcg oom handling could be considerably skewed if the file was
>>>>> shared between more memcgs.
>>>> Yes, and that's one of the reasons why I didn't touched the memcg by this
>>>> and only affected the classic OOM killer.
>>> oom_badness is for all oom handlers, including memcg. Maybe I have
>>> misread an earlier patch but I do not see anything specific to global
>>> oom handling.
>> As far as I can see the oom_badness() function is only used in
>> oom_kill.c and in procfs to return the oom score. Did I missed
>> something?
> oom_kill.c implements most of the oom killer functionality. Memcg oom
> killing is a part of that. Have a look at select_bad_process.
Ah! So mem_cgroup_scan_tasks() calls oom_evaluate_task for each task in
the control group.
Thanks for pointing that out, that was absolutely not obvious to me.
Is that a show stopper? How should we address this?
Christian.
WARNING: multiple messages have this Message-ID (diff)
From: "Christian König" <christian.koenig@amd.com>
To: "Michal Hocko" <mhocko@suse.com>,
"Christian König" <ckoenig.leichtzumerken@gmail.com>
Cc: andrey.grodzovsky@amd.com, linux-mm@kvack.org,
nouveau@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
hughd@google.com, linux-kernel@vger.kernel.org,
amd-gfx@lists.freedesktop.org, linux-fsdevel@vger.kernel.org,
viro@zeniv.linux.org.uk, daniel@ffwll.ch,
linux-tegra@vger.kernel.org, alexander.deucher@amd.com,
akpm@linux-foundation.org, linux-media@vger.kernel.org
Subject: Re: [PATCH 03/13] mm: shmem: provide oom badness for shmem files
Date: Thu, 9 Jun 2022 16:29:46 +0200 [thread overview]
Message-ID: <d4a19481-7a9f-19bf-c270-d89baa0970fc@amd.com> (raw)
In-Reply-To: <YqIB0bavUeU8Abwl@dhcp22.suse.cz>
Am 09.06.22 um 16:21 schrieb Michal Hocko:
> On Thu 09-06-22 16:10:33, Christian König wrote:
>> Am 09.06.22 um 14:57 schrieb Michal Hocko:
>>> On Thu 09-06-22 14:16:56, Christian König wrote:
>>>> Am 09.06.22 um 11:18 schrieb Michal Hocko:
>>>>> On Tue 31-05-22 11:59:57, Christian König wrote:
>>>>>> This gives the OOM killer an additional hint which processes are
>>>>>> referencing shmem files with potentially no other accounting for them.
>>>>>>
>>>>>> Signed-off-by: Christian König <christian.koenig@amd.com>
>>>>>> ---
>>>>>> mm/shmem.c | 6 ++++++
>>>>>> 1 file changed, 6 insertions(+)
>>>>>>
>>>>>> diff --git a/mm/shmem.c b/mm/shmem.c
>>>>>> index 4b2fea33158e..a4ad92a16968 100644
>>>>>> --- a/mm/shmem.c
>>>>>> +++ b/mm/shmem.c
>>>>>> @@ -2179,6 +2179,11 @@ unsigned long shmem_get_unmapped_area(struct file *file,
>>>>>> return inflated_addr;
>>>>>> }
>>>>>> +static long shmem_oom_badness(struct file *file)
>>>>>> +{
>>>>>> + return i_size_read(file_inode(file)) >> PAGE_SHIFT;
>>>>>> +}
>>>>> This doesn't really represent the in memory size of the file, does it?
>>>> Well the file could be partially or fully swapped out as anonymous memory or
>>>> the address space only sparse populated, but even then just using the file
>>>> size as OOM badness sounded like the most straightforward approach to me.
>>> It covers hole as well, right?
>> Yes, exactly.
> So let's say I have a huge sparse shmem file. I will get killed because
> the oom_badness of such a file would be large as well...
Yes, correct. But I of hand don't see how we could improve that accounting.
>>>> What could happen is that the file is also mmaped and we double account.
>>>>
>>>>> Also the memcg oom handling could be considerably skewed if the file was
>>>>> shared between more memcgs.
>>>> Yes, and that's one of the reasons why I didn't touched the memcg by this
>>>> and only affected the classic OOM killer.
>>> oom_badness is for all oom handlers, including memcg. Maybe I have
>>> misread an earlier patch but I do not see anything specific to global
>>> oom handling.
>> As far as I can see the oom_badness() function is only used in
>> oom_kill.c and in procfs to return the oom score. Did I missed
>> something?
> oom_kill.c implements most of the oom killer functionality. Memcg oom
> killing is a part of that. Have a look at select_bad_process.
Ah! So mem_cgroup_scan_tasks() calls oom_evaluate_task for each task in
the control group.
Thanks for pointing that out, that was absolutely not obvious to me.
Is that a show stopper? How should we address this?
Christian.
next prev parent reply other threads:[~2022-06-09 14:30 UTC|newest]
Thread overview: 145+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-31 9:59 Per file OOM badness Christian König
2022-05-31 9:59 ` Christian König
2022-05-31 9:59 ` [Nouveau] " Christian König
2022-05-31 9:59 ` [PATCH 01/13] fs: add OOM badness callback to file_operatrations struct Christian König
2022-05-31 9:59 ` Christian König
2022-05-31 9:59 ` [Nouveau] " Christian König
2022-05-31 9:59 ` [PATCH 02/13] oom: take per file badness into account Christian König
2022-05-31 9:59 ` Christian König
2022-05-31 9:59 ` [Nouveau] " Christian König
2022-05-31 9:59 ` [PATCH 03/13] mm: shmem: provide oom badness for shmem files Christian König
2022-05-31 9:59 ` Christian König
2022-05-31 9:59 ` [Nouveau] " Christian König
2022-06-09 9:18 ` Michal Hocko
2022-06-09 9:18 ` [Nouveau] " Michal Hocko
2022-06-09 9:18 ` Michal Hocko
2022-06-09 9:18 ` [Intel-gfx] " Michal Hocko
2022-06-09 12:16 ` Christian König
2022-06-09 12:16 ` Christian König
2022-06-09 12:16 ` [Intel-gfx] " Christian König
2022-06-09 12:16 ` [Nouveau] " Christian König
2022-06-09 12:57 ` Michal Hocko
2022-06-09 12:57 ` [Nouveau] " Michal Hocko
2022-06-09 12:57 ` Michal Hocko
2022-06-09 12:57 ` [Intel-gfx] " Michal Hocko
2022-06-09 14:10 ` Christian König
2022-06-09 14:10 ` Christian König
2022-06-09 14:10 ` [Nouveau] " Christian König
2022-06-09 14:21 ` Michal Hocko
2022-06-09 14:21 ` [Nouveau] " Michal Hocko
2022-06-09 14:21 ` Michal Hocko
2022-06-09 14:21 ` [Intel-gfx] " Michal Hocko
2022-06-09 14:29 ` Christian König [this message]
2022-06-09 14:29 ` Christian König
2022-06-09 14:29 ` [Intel-gfx] " Christian König
2022-06-09 14:29 ` [Nouveau] " Christian König
2022-06-09 15:07 ` Michal Hocko
2022-06-09 15:07 ` [Nouveau] " Michal Hocko
2022-06-09 15:07 ` Michal Hocko
2022-06-09 15:07 ` [Intel-gfx] " Michal Hocko
2022-06-10 10:58 ` Christian König
2022-06-10 10:58 ` Christian König
2022-06-10 10:58 ` [Nouveau] " Christian König
2022-06-10 11:44 ` Michal Hocko
2022-06-10 11:44 ` [Nouveau] " Michal Hocko
2022-06-10 11:44 ` Michal Hocko
2022-06-10 11:44 ` [Intel-gfx] " Michal Hocko
2022-06-10 12:17 ` Christian König
2022-06-10 12:17 ` Christian König
2022-06-10 12:17 ` [Intel-gfx] " Christian König
2022-06-10 12:17 ` [Nouveau] " Christian König
2022-06-10 14:16 ` Michal Hocko
2022-06-10 14:16 ` [Nouveau] " Michal Hocko
2022-06-10 14:16 ` Michal Hocko
2022-06-10 14:16 ` [Intel-gfx] " Michal Hocko
2022-06-11 8:06 ` Christian König
2022-06-11 8:06 ` Christian König
2022-06-11 8:06 ` [Intel-gfx] " Christian König
2022-06-11 8:06 ` [Nouveau] " Christian König
2022-06-13 7:45 ` Michal Hocko
2022-06-13 7:45 ` [Nouveau] " Michal Hocko
2022-06-13 7:45 ` Michal Hocko
2022-06-13 7:45 ` [Intel-gfx] " Michal Hocko
2022-06-13 11:50 ` Christian König
2022-06-13 11:50 ` Christian König
2022-06-13 11:50 ` [Intel-gfx] " Christian König
2022-06-13 11:50 ` [Nouveau] " Christian König
2022-06-13 12:11 ` Michal Hocko
2022-06-13 12:11 ` [Nouveau] " Michal Hocko
2022-06-13 12:11 ` Michal Hocko
2022-06-13 12:11 ` [Intel-gfx] " Michal Hocko
2022-06-13 12:55 ` [Nouveau] " Christian König
2022-06-13 12:55 ` Christian König
2022-06-13 12:55 ` Christian König
2022-06-13 12:55 ` [Intel-gfx] " Christian König
2022-06-13 14:11 ` Michal Hocko
2022-06-13 14:11 ` [Nouveau] " Michal Hocko
2022-06-13 14:11 ` Michal Hocko
2022-06-13 14:11 ` Michal Hocko
2022-06-15 12:35 ` Christian König
2022-06-15 12:35 ` Christian König
2022-06-15 12:35 ` [Intel-gfx] " Christian König
2022-06-15 12:35 ` [Nouveau] " Christian König
2022-06-15 13:15 ` Michal Hocko
2022-06-15 13:15 ` [Nouveau] " Michal Hocko
2022-06-15 13:15 ` Michal Hocko
2022-06-15 13:15 ` [Intel-gfx] " Michal Hocko
2022-06-15 14:24 ` Christian König
2022-06-15 14:24 ` Christian König
2022-06-15 14:24 ` [Intel-gfx] " Christian König
2022-06-15 14:24 ` [Nouveau] " Christian König
2022-06-13 9:08 ` Michel Dänzer
2022-06-13 9:08 ` [Nouveau] " Michel Dänzer
2022-06-13 9:08 ` [Intel-gfx] " Michel Dänzer
2022-06-13 9:08 ` Michel Dänzer
2022-06-13 9:11 ` Christian König
2022-06-13 9:11 ` Christian König
2022-06-13 9:11 ` [Intel-gfx] " Christian König
2022-06-13 9:11 ` [Nouveau] " Christian König
2022-06-09 15:19 ` Felix Kuehling
2022-06-09 15:19 ` Felix Kuehling
2022-06-09 15:19 ` [Intel-gfx] " Felix Kuehling
2022-06-09 15:19 ` [Nouveau] " Felix Kuehling
2022-06-09 15:22 ` Christian König
2022-06-09 15:22 ` Christian König
2022-06-09 15:22 ` [Intel-gfx] " Christian König
2022-06-09 15:22 ` [Nouveau] " Christian König
2022-06-09 15:54 ` Michal Hocko
2022-06-09 15:54 ` [Nouveau] " Michal Hocko
2022-06-09 15:54 ` Michal Hocko
2022-06-09 15:54 ` [Intel-gfx] " Michal Hocko
2022-05-31 9:59 ` [PATCH 04/13] dma-buf: provide oom badness for DMA-buf files Christian König
2022-05-31 9:59 ` Christian König
2022-05-31 9:59 ` [Nouveau] " Christian König
2022-05-31 9:59 ` [PATCH 05/13] drm/gem: adjust per file OOM badness on handling buffers Christian König
2022-05-31 9:59 ` Christian König
2022-05-31 9:59 ` [Nouveau] " Christian König
2022-05-31 10:00 ` [PATCH 06/13] drm/gma500: use drm_oom_badness Christian König
2022-05-31 10:00 ` Christian König
2022-05-31 10:00 ` [Nouveau] " Christian König
2022-05-31 10:00 ` [PATCH 07/13] drm/amdgpu: Use drm_oom_badness for amdgpu Christian König
2022-05-31 10:00 ` Christian König
2022-05-31 10:00 ` [Nouveau] " Christian König
2022-05-31 10:00 ` [PATCH 08/13] drm/radeon: use drm_oom_badness Christian König
2022-05-31 10:00 ` Christian König
2022-05-31 10:00 ` [Nouveau] " Christian König
2022-05-31 10:00 ` [PATCH 09/13] drm/i915: " Christian König
2022-05-31 10:00 ` Christian König
2022-05-31 10:00 ` [Nouveau] " Christian König
2022-05-31 10:00 ` [PATCH 10/13] drm/nouveau: " Christian König
2022-05-31 10:00 ` Christian König
2022-05-31 10:00 ` [Nouveau] " Christian König
2022-05-31 10:00 ` [PATCH 11/13] drm/omap: " Christian König
2022-05-31 10:00 ` Christian König
2022-05-31 10:00 ` [Nouveau] " Christian König
2022-05-31 10:00 ` [PATCH 12/13] drm/vmwgfx: " Christian König
2022-05-31 10:00 ` Christian König
2022-05-31 10:00 ` [Nouveau] " Christian König
2022-05-31 10:00 ` [PATCH 13/13] drm/tegra: " Christian König
2022-05-31 10:00 ` Christian König
2022-05-31 10:00 ` [Nouveau] " Christian König
2022-05-31 22:00 ` Per file OOM badness Alex Deucher
2022-05-31 22:00 ` Alex Deucher
2022-05-31 22:00 ` [Intel-gfx] " Alex Deucher
2022-05-31 22:00 ` Alex Deucher
2022-05-31 22:00 ` [Nouveau] " Alex Deucher
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=d4a19481-7a9f-19bf-c270-d89baa0970fc@amd.com \
--to=christian.koenig@amd.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=andrey.grodzovsky@amd.com \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=daniel@ffwll.ch \
--cc=hughd@google.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-tegra@vger.kernel.org \
--cc=mhocko@suse.com \
--cc=nouveau@lists.freedesktop.org \
--cc=viro@zeniv.linux.org.uk \
/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: link
Be 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.