mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: torvalds@linux-foundation.org
Cc: hugh@veritas.com, ak@linux.intel.com, ian.campbell@citrix.com,
	jakub@redhat.com, linux-kernel@vger.kernel.org,
	jesper.nilsson@axis.com, hannes@cmpxchg.org,
	arjan@linux.intel.com, akpm@linux-foundation.org
Subject: Re: [PATCH] Fix print out of function which called WARN_ON()
Date: Sun, 17 May 2009 15:24:54 -0700 (PDT)	[thread overview]
Message-ID: <20090517.152454.91703958.davem@davemloft.net> (raw)
In-Reply-To: <alpine.LFD.2.01.0905171502160.3301@localhost.localdomain>

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sun, 17 May 2009 15:18:19 -0700 (PDT)

> The thing is, on at least x86-64, any function using va_start() will 
> allocate something like 64 bytes of stack space for the reg-save area. I'm 
> not quite sure _why_ it does that, but it's very irritating, and it showed 
> up quite clearly in some of the stackspace usage things.
> 
> I even sent the gcc people a patch to fix the worst of it (gcc used to 
> allocate about twice as much space because it also had a XMM save area 
> even if you compiled without XMM support or something like that), but my 
> point is, I'm afraid there is still a noticeable gap on the stack due to 
> this, at least for the _fmt() case.

I ran into this issue on sparc64 while helping someone investigate
stack usage there.

There is some strageness wrt. varargs in that it seems that the opaque
object used to reference varargs is effectively an array which
includes first the arguments passed in registers and then the
non-register stack args.

I never got down to the details yet, but on sparc64 currently we
always eat that extra space (in addition to the normal register window
stack space costs) and I had intended to look into eliminating the
varargs incoming argument save slots for cases where we are not doing
any varargs stuff at all.

  reply	other threads:[~2009-05-17 22:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-15 16:17 Ian Campbell
2009-05-15 17:52 ` Linus Torvalds
2009-05-15 19:50   ` Andi Kleen
2009-05-16 20:47     ` Linus Torvalds
2009-05-17 14:43       ` Hugh Dickins
2009-05-17 22:18         ` Linus Torvalds
2009-05-17 22:24           ` David Miller [this message]
2009-05-17 22:47             ` Linus Torvalds
2009-05-17 22:45           ` Hugh Dickins
2009-05-17 22:54             ` Linus Torvalds
2009-05-18  9:09       ` Ian Campbell
2009-05-18 14:11         ` Arjan van de Ven

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=20090517.152454.91703958.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@linux.intel.com \
    --cc=hannes@cmpxchg.org \
    --cc=hugh@veritas.com \
    --cc=ian.campbell@citrix.com \
    --cc=jakub@redhat.com \
    --cc=jesper.nilsson@axis.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.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

all inboxes | Powered by JetHome®