public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Keith Owens <kaos@sgi.com>
To: linux-ia64@vger.kernel.org
Subject: Re: Why does salinfo_log_read_cpu use kmalloc?
Date: Thu, 09 Oct 2003 03:13:50 +0000	[thread overview]
Message-ID: <marc-linux-ia64-106566927917419@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-106559698807998@msgid-missing>

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.


      parent reply	other threads:[~2003-10-09  3:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-08  7:08 Why does salinfo_log_read_cpu use kmalloc? Keith Owens
2003-10-08 11:47 ` Matthew Wilcox
2003-10-08 12:48 ` Keith Owens
2003-10-08 15:55 ` Bjorn Helgaas
2003-10-09  3:13 ` Keith Owens [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=marc-linux-ia64-106566927917419@msgid-missing \
    --to=kaos@sgi.com \
    --cc=linux-ia64@vger.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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox