From: "Li, Aubrey" <aubrey.li@linux.intel.com>
To: Andy Lutomirski <luto@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
"H. Peter Anvin" <hpa@zytor.com>, Andi Kleen <ak@linux.intel.com>,
Tim Chen <tim.c.chen@linux.intel.com>,
Dave Hansen <dave.hansen@intel.com>,
Arjan van de Ven <arjan@linux.intel.com>,
Alexey Dobriyan <adobriyan@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
aubrey.li@intel.com, Linux API <linux-api@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v14 1/3] /proc/pid/status: Add support for architecture specific output
Date: Fri, 12 Apr 2019 08:55:19 +0800 [thread overview]
Message-ID: <3507770f-9004-458a-98c3-5c1884ac57ef@linux.intel.com> (raw)
In-Reply-To: <3c2a8a1a-ed4b-348e-f06f-f71dbf64bbba@linux.intel.com>
On 2019/4/11 9:02, Li, Aubrey wrote:
> On 2019/4/10 22:54, Andy Lutomirski wrote:
>> On Tue, Apr 9, 2019 at 8:40 PM Li, Aubrey <aubrey.li@linux.intel.com> wrote:
>>>
>>> On 2019/4/10 10:36, Li, Aubrey wrote:
>>>> On 2019/4/10 10:25, Andy Lutomirski wrote:
>>>>> On Tue, Apr 9, 2019 at 7:20 PM Li, Aubrey <aubrey.li@linux.intel.com> wrote:
>>>>>>
>>>>>> On 2019/4/10 9:58, Andy Lutomirski wrote:
>>>>>>> On Tue, Apr 9, 2019 at 6:55 PM Aubrey Li <aubrey.li@linux.intel.com> wrote:
>>>>>>>>
>>>>>>>> The architecture specific information of the running processes could
>>>>>>>> be useful to the userland. Add support to examine process architecture
>>>>>>>> specific information externally.
>>>>>>>>
>>>>>>>> Signed-off-by: Aubrey Li <aubrey.li@linux.intel.com>
>>>>>>>> Cc: Peter Zijlstra <peterz@infradead.org>
>>>>>>>> Cc: Andi Kleen <ak@linux.intel.com>
>>>>>>>> Cc: Tim Chen <tim.c.chen@linux.intel.com>
>>>>>>>> Cc: Dave Hansen <dave.hansen@intel.com>
>>>>>>>> Cc: Arjan van de Ven <arjan@linux.intel.com>
>>>>>>>> Cc: Linux API <linux-api@vger.kernel.org>
>>>>>>>> Cc: Alexey Dobriyan <adobriyan@gmail.com>
>>>>>>>> Cc: Andrew Morton <akpm@linux-foundation.org>
>>>>>>>> ---
>>>>>>>> fs/proc/array.c | 5 +++++
>>>>>>>> include/linux/proc_fs.h | 2 ++
>>>>>>>> 2 files changed, 7 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/fs/proc/array.c b/fs/proc/array.c
>>>>>>>> index 2edbb657f859..331592a61718 100644
>>>>>>>> --- a/fs/proc/array.c
>>>>>>>> +++ b/fs/proc/array.c
>>>>>>>> @@ -401,6 +401,10 @@ static inline void task_thp_status(struct seq_file *m, struct mm_struct *mm)
>>>>>>>> seq_printf(m, "THP_enabled:\t%d\n", thp_enabled);
>>>>>>>> }
>>>>>>>>
>>>>>>>> +void __weak arch_proc_pid_status(struct seq_file *m, struct task_struct *task)
>>>>>>>> +{
>>>>>>>> +}
>>>>>>>
>>>>>>> This pointlessly bloats other architectures. Do this instead in an
>>>>>>> appropriate header:
>>>>>>>
>>>>>>> #ifndef arch_proc_pid_status
>>>>>>> static inline void arch_proc_pid_status(...)
>>>>>>> {
>>>>>>> }
>>>>>>> #endif
>>>>>>>
>>>>>>
>>>>>> I saw a bunch of similar weak functions, is it not acceptable?
>>>>>>
>>>>>> fs/proc$ grep weak *.c
>>>>>> cpuinfo.c:__weak void arch_freq_prepare_all(void)
>>>>>> meminfo.c:void __attribute__((weak)) arch_report_meminfo(struct seq_file *m)
>>>>>> vmcore.c:int __weak elfcorehdr_alloc(unsigned long long *addr, unsigned long long *size)
>>>>>> vmcore.c:void __weak elfcorehdr_free(unsigned long long addr)
>>>>>> vmcore.c:ssize_t __weak elfcorehdr_read(char *buf, size_t count, u64 *ppos)
>>>>>> vmcore.c:ssize_t __weak elfcorehdr_read_notes(char *buf, size_t count, u64 *ppos)
>>>>>> vmcore.c:int __weak remap_oldmem_pfn_range(struct vm_area_struct *vma,
>>>>>> vmcore.c:ssize_t __weak
>>>>>
>>>>> I think they're acceptable, but I don't personally like them.
>>>>>
>>>>
>>>> okay, let me try to see if I can refine it in an appropriate way.
>>>
>>> Hi Andy,
>>>
>>> Is this what you want?
>>>
>>> Thanks,
>>> -Aubrey
>>>
>>> ====================================================================
>>> diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
>>> index 2bb3a648fc12..82d77d3aefff 100644
>>> --- a/arch/x86/include/asm/processor.h
>>> +++ b/arch/x86/include/asm/processor.h
>>> @@ -990,5 +990,8 @@ enum l1tf_mitigations {
>>> };
>>>
>>> extern enum l1tf_mitigations l1tf_mitigation;
>>> +/* Add support for architecture specific output in /proc/pid/status */
>>> +void arch_proc_pid_status(struct seq_file *m, struct task_struct *task);
>>> +#define arch_proc_pid_status arch_proc_pid_status
>>>
>>> #endif /* _ASM_X86_PROCESSOR_H */
>>> diff --git a/fs/proc/array.c b/fs/proc/array.c
>>> index 2edbb657f859..fd65a6ba2864 100644
>>> --- a/fs/proc/array.c
>>> +++ b/fs/proc/array.c
>>> @@ -401,6 +401,11 @@ static inline void task_thp_status(struct seq_file *m, struct mm_struct *mm)
>>> seq_printf(m, "THP_enabled:\t%d\n", thp_enabled);
>>> }
>>>
>>> +/* Add support for architecture specific output in /proc/pid/status */
>>> +#ifndef arch_proc_pid_status
>>> +#define arch_proc_pid_status(m, task)
>>> +#endif
>>> +
>>> int proc_pid_status(struct seq_file *m, struct pid_namespace *ns,
>>> struct pid *pid, struct task_struct *task)
>>> {
>>> @@ -424,6 +429,7 @@ int proc_pid_status(struct seq_file *m, struct pid_namespace *ns,
>>> task_cpus_allowed(m, task);
>>> cpuset_task_status_allowed(m, task);
>>> task_context_switch_counts(m, task);
>>> + arch_proc_pid_status(m, task);
>>> return 0;
>>> }
>>>
>>
>> Yes. But I still think it would be nicer to separate the arch stuff
>> into its own file. Others might reasonably disagree with me.
>>
> I like arch_status, I proposed but no other arch shows interesting in it.
>
> I think the problem is similar for x86_status, it does not make sense for
> those x86 platform without AVX512 to have an empty arch file. I personally
> don't like [arch]_status because the code may become unclean if more arches
> added in future.
>
> Maybe it's too early to have a separated arch staff file for now.
Hi Andy,
Is it acceptable to you if I make the above change and post v15?
Thanks,
-Aubrey
prev parent reply other threads:[~2019-04-12 0:55 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-10 1:53 [PATCH v14 1/3] /proc/pid/status: Add support for architecture specific output Aubrey Li
2019-04-10 1:53 ` [PATCH v14 2/3] x86,/proc/pid/status: Add AVX-512 usage elapsed time Aubrey Li
2019-04-10 1:53 ` [PATCH v14 3/3] Documentation/filesystems/proc.txt: add AVX512_elapsed_ms Aubrey Li
2019-04-10 1:58 ` [PATCH v14 1/3] /proc/pid/status: Add support for architecture specific output Andy Lutomirski
2019-04-10 2:20 ` Li, Aubrey
2019-04-10 2:25 ` Andy Lutomirski
2019-04-10 2:36 ` Li, Aubrey
2019-04-10 3:39 ` Li, Aubrey
2019-04-10 14:54 ` Andy Lutomirski
2019-04-11 1:02 ` Li, Aubrey
2019-04-12 0:55 ` Li, Aubrey [this message]
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=3507770f-9004-458a-98c3-5c1884ac57ef@linux.intel.com \
--to=aubrey.li@linux.intel.com \
--cc=adobriyan@gmail.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=arjan@linux.intel.com \
--cc=aubrey.li@intel.com \
--cc=dave.hansen@intel.com \
--cc=hpa@zytor.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=tim.c.chen@linux.intel.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: 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.