From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrea Righi <righi.andrea@gmail.com>,
akpm@linux-foundation.org, linux-mm@kvack.org,
linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] mm: unify pmd_free() implementation
Date: Mon, 28 Jul 2008 11:58:58 -0500 [thread overview]
Message-ID: <1217264339.3503.97.camel@localhost.localdomain> (raw)
In-Reply-To: <alpine.LFD.1.10.0807280937150.3486@nehalem.linux-foundation.org>
On Mon, 2008-07-28 at 09:45 -0700, Linus Torvalds wrote:
>
> On Mon, 28 Jul 2008, James Bottomley wrote:
> >
> > Are you sure about this (the barrier)?
>
> I'm sure. Try it. It perturbs the code quite a bit to have a function call
> in the thing, because it
>
> - clobbers all callee-clobbered registers.
>
> This means that all functions that _used_ to be leaf functions and
> needed no stack frame at all (because they were simple enough to use
> only the callee-clobbered registers) are suddenly now going to be
> significantly more costly.
>
> Ergo: you get more stack movement with save/restore crud.
>
> - it is a barrier wrt any variables that may be visible externally
> (perhaps because they had their address taken), so it forces a flush to
> memory for those.
>
> - if it has arguments and return values, it also ends up forcing a
> totally unnecessary argument setup (and all the fixed register crap
> that involves, which means that you lost almost all your register
> allocation freedom - not that you likely care, since most of your
> registers are dead _anyway_ around the function call)
>
> So empty functions calls are _deadly_ especially if the code was a leaf
> function before, and suddenly isn't any more.
>
> On the other hand, there are also many cases where function calls won't
> matter much at all. If you had other function calls around that same area,
> all the above issues essentially go away, since your registers are dead
> anyway, and the function obviously wasn't a leaf function before the new
> call.
>
> So it does depend quite a bit on the pattern of use. And yes, function
> argument setup can be a big part of it too.
Sorry ... should have been clearer. My main concern is the cost of
barrier() which is just a memory clobber ... we have to use barriers to
place the probe points correctly in the code.
We already get that spilling function clobbered registers to stack (or
elsewhere) and yanking values out of the optimisation stream for the
arguments is pretty costly ... although the current LTT tracepoint code
argues that this cost can be borne.
James
next prev parent reply other threads:[~2008-07-28 16:59 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-28 15:51 [PATCH 1/1] mm: unify pmd_free() implementation Andrea Righi
2008-07-28 15:53 ` Linus Torvalds
2008-07-28 16:17 ` Andrea Righi
2008-07-28 16:17 ` Andrea Righi
2008-07-28 16:27 ` KOSAKI Motohiro
2008-07-28 17:19 ` Andrea Righi
2008-07-28 20:30 ` Andrew Morton
2008-07-28 20:46 ` Jeremy Fitzhardinge
2008-07-28 22:53 ` [PATCH 1/1] mm: unify pmd_free() and __pmd_free_tlb() implementation Andrea Righi
2008-07-31 16:17 ` Ingo Molnar
2008-07-31 16:59 ` Andrea Righi
2008-07-28 16:17 ` [PATCH 1/1] mm: unify pmd_free() implementation James Bottomley
2008-07-28 16:45 ` Linus Torvalds
2008-07-28 16:58 ` James Bottomley [this message]
2008-07-28 17:10 ` Linus Torvalds
2008-07-28 20:08 ` [PATCH 1/1] mm: unify pmd_free() implementation -> instrumentation Mathieu Desnoyers
2008-07-28 20:08 ` Mathieu Desnoyers
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=1217264339.3503.97.camel@localhost.localdomain \
--to=james.bottomley@hansenpartnership.com \
--cc=akpm@linux-foundation.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=righi.andrea@gmail.com \
--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;
as well as URLs for NNTP newsgroup(s).