All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David S. Miller" <davem@redhat.com>
To: Paul Jackson <pj@sgi.com>
Cc: colpatch@us.ibm.com, linux-kernel@vger.kernel.org,
	mbligh@aracnet.com, akpm@osdl.org, haveblue@us.ibm.com,
	hch@infradead.org, wli@holomorphy.com
Subject: Re: Sparc64, cpumask_t and struct arguments (was: [PATCH] Introduce nodemask_t ADT)
Date: Fri, 26 Mar 2004 14:54:23 -0800	[thread overview]
Message-ID: <20040326145423.74c1ce52.davem@redhat.com> (raw)
In-Reply-To: <20040326143648.5be0e221.pj@sgi.com>

On Fri, 26 Mar 2004 14:36:48 -0800
Paul Jackson <pj@sgi.com> wrote:

> However, as I recall, you recommend against passing structs on the
> Sparc64 processor and compilation environment.  Am I recalling
> correctly?

It's a problem moreso on sparc32.  Structures there have to be passed
"by reference", which means it gets copied onto the stack and then a
pointer to that data area is passed as the actual parameter.

Sparc64 does the same but only _iff_ the structure does not fit entirely
in the remaining argument registers or the structures size is greater
than 32-bytes.

The cross-call functions you reference are slow path code.  And whats
more currently none of that code supports more than 64 cpus, although
I'll have to add support for larger numbers later.

>  5) The cpu_clear(i, mask) on about line 534 of smp.c confuses me, as it
>     seems to be changing a local copy of 'mask' that no one will examine
>     later.  What purpose does it serve?  See this line annotated with
>     "No affect??" in the changes, below.

No, mask is the top level mask value, we assign it to local variable
in order to do this or that operation on it.  Once we've really send
the XCALL message to the processor, we clear it in 'mask' only then.


  reply	other threads:[~2004-03-26 22:55 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-18 23:04 [PATCH] Introduce nodemask_t ADT [0/7] Matthew Dobson
2004-03-18 23:23 ` Jesse Barnes
2004-03-18 23:32   ` Martin J. Bligh
2004-03-18 23:37     ` Jesse Barnes
2004-03-18 23:43       ` Martin J. Bligh
2004-03-18 23:59         ` Jesse Barnes
2004-03-19 16:20           ` Martin J. Bligh
2004-03-19  0:58         ` Zwane Mwaikambo
2004-03-19  1:11           ` Jesse Barnes
2004-03-19  1:34             ` Zwane Mwaikambo
2004-03-19  1:40               ` Jesse Barnes
2004-03-19  1:08         ` Paul Jackson
2004-03-19  0:01     ` Matthew Dobson
2004-03-18 23:58   ` Matthew Dobson
2004-03-19  2:55   ` William Lee Irwin III
2004-03-19  0:59 ` Paul Jackson
2004-03-19  1:19   ` Matthew Dobson
2004-03-19  1:45     ` Paul Jackson
2004-03-19 22:51       ` Matthew Dobson
2004-03-19 23:42         ` Paul Jackson
2004-03-19  1:48     ` Paul Jackson
2004-03-19  1:56     ` Paul Jackson
2004-03-19 23:02       ` Matthew Dobson
2004-03-20  0:59         ` Paul Jackson
2004-03-20  3:18           ` William Lee Irwin III
2004-03-20  6:09             ` Paul Jackson
2004-03-20  9:36               ` William Lee Irwin III
2004-03-22 23:59                 ` Paul Jackson
2004-03-23  2:12                   ` William Lee Irwin III
2004-03-23  1:21                 ` Paul Jackson
2004-03-23  2:10                   ` William Lee Irwin III
2004-03-23  1:24                 ` Paul Jackson
2004-03-20  8:02             ` Paul Jackson
2004-03-20 11:13               ` William Lee Irwin III
2004-03-21  4:19                 ` Paul Jackson
2004-03-21  4:36                   ` William Lee Irwin III
2004-03-21  7:59                     ` Nick Piggin
2004-03-23  1:12                 ` Paul Jackson
2004-03-23  2:09                   ` William Lee Irwin III
2004-03-23  2:39                     ` Paul Jackson
2004-03-23  3:13                       ` William Lee Irwin III
2004-03-23  3:36                         ` Paul Jackson
2004-03-23  3:59                           ` William Lee Irwin III
2004-03-23  4:03                             ` Paul Jackson
     [not found]                             ` <20040325012457.51f708c7.pj@sgi.com>
     [not found]                               ` <20040325101827.GO791@holomorphy.com>
2004-03-26 22:36                                 ` Sparc64, cpumask_t and struct arguments (was: [PATCH] Introduce nodemask_t ADT) Paul Jackson
2004-03-26 22:54                                   ` David S. Miller [this message]
2004-03-26 23:18                                     ` Paul Jackson
2004-03-26 23:29                                     ` Paul Jackson
2004-03-27  0:08                                       ` David S. Miller
2004-03-27  0:50                                         ` Paul Jackson
2004-03-26 23:37                                     ` Paul Jackson

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=20040326145423.74c1ce52.davem@redhat.com \
    --to=davem@redhat.com \
    --cc=akpm@osdl.org \
    --cc=colpatch@us.ibm.com \
    --cc=haveblue@us.ibm.com \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@aracnet.com \
    --cc=pj@sgi.com \
    --cc=wli@holomorphy.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.