Why does salinfo_log_read_cpu use kmalloc?

Why does salinfo_log_read_cpu use kmalloc?

[Keith Owens]

Why does arch/ia64/kernel/salinfo.c::salinfo_log_read_cpu() use
kmalloc() for the log buffer?  The code is running virtual with
interrupts enabled, SAL_GET_STATE_INFO has no special requirements for
the buffer attributes, so why not use vmalloc()?

Re: Why does salinfo_log_read_cpu use kmalloc?

[Matthew Wilcox]

On Wed, Oct 08, 2003 at 05:08:14PM +1000, Keith Owens wrote:
> Why does arch/ia64/kernel/salinfo.c::salinfo_log_read_cpu() use
> kmalloc() for the log buffer?  The code is running virtual with
> interrupts enabled, SAL_GET_STATE_INFO has no special requirements for
> the buffer attributes, so why not use vmalloc()?

I don't see a function called salinfo_log_read_cpu in
arch/ia64/kernel/salinfo.c ... moreover, I don't see any occurrences of
the string "alloc" in that file.  Sure you're looking at the right tree?

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: Why does salinfo_log_read_cpu use kmalloc?

[Keith Owens]

On Wed, 8 Oct 2003 12:47:39 +0100, 
Matthew Wilcox <willy@debian.org> wrote:
>On Wed, Oct 08, 2003 at 05:08:14PM +1000, Keith Owens wrote:
>> Why does arch/ia64/kernel/salinfo.c::salinfo_log_read_cpu() use
>> kmalloc() for the log buffer?  The code is running virtual with
>> interrupts enabled, SAL_GET_STATE_INFO has no special requirements for
>> the buffer attributes, so why not use vmalloc()?
>
>I don't see a function called salinfo_log_read_cpu in
>arch/ia64/kernel/salinfo.c ... moreover, I don't see any occurrences of
>the string "alloc" in that file.  Sure you're looking at the right tree?

2.4.22-ia64-030909 and 2.4.22 pristine.  For some reason, this code is
not in the 2.6 trees.

Re: Why does salinfo_log_read_cpu use kmalloc?

[Bjorn Helgaas]

On Wednesday 08 October 2003 1:08 am, Keith Owens wrote:
> Why does arch/ia64/kernel/salinfo.c::salinfo_log_read_cpu() use
> kmalloc() for the log buffer?  The code is running virtual with
> interrupts enabled, SAL_GET_STATE_INFO has no special requirements for
> the buffer attributes, so why not use vmalloc()?

It's usually called via smp_call_function_single(), which uses
an IPI to make it happen on another processor.  I thought
this meant the function got called with interrupts disabled,
but I could be wrong.

And yes, I do need to push this to 2.6.  It's on my to-do list.

Bjorn

Re: Why does salinfo_log_read_cpu use kmalloc?

[Keith Owens]

On Wed, 8 Oct 2003 09:55:44 -0600, 
Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
>On Wednesday 08 October 2003 1:08 am, Keith Owens wrote:
>> Why does arch/ia64/kernel/salinfo.c::salinfo_log_read_cpu() use
>> kmalloc() for the log buffer?  The code is running virtual with
>> interrupts enabled, SAL_GET_STATE_INFO has no special requirements for
>> the buffer attributes, so why not use vmalloc()?
>
>It's usually called via smp_call_function_single(), which uses
>an IPI to make it happen on another processor.  I thought
>this meant the function got called with interrupts disabled,
>but I could be wrong.

So the question becomes, why use smp_call_function_single() and have
the code run disabled?  salinfo_log_read_cpu() is performing work on
behalf of a user process, we can use set_cpus_allowed() and let the
scheduler run the code on the required cpu with interrupts enabled.

Any objections if I do a patch to replace smp_call_function_single()
with set_cpus_allowed(), so reading the records from SAL does not block
OS interrupts?  For the special case when the task is on the cpu that
salinfo wants to read from, the existing code does not use IPI so it
calls SAL with interrupts enabled.