[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1403311749500.14882@ionos.tec.linutronix.de>
Date: Mon, 31 Mar 2014 17:51:51 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Viresh Kumar <viresh.kumar@...aro.org>
cc: Lists linaro-kernel <linaro-kernel@...ts.linaro.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Frédéric Weisbecker <fweisbec@...il.com>,
Linaro Networking <linaro-networking@...aro.org>,
Arvind Chauhan <Arvind.Chauhan@....com>
Subject: Re: [PATCH 00/16] timers/hrtimers: Minor cleanups: Part II
On Mon, 31 Mar 2014, Viresh Kumar wrote:
> On 31 March 2014 19:08, Thomas Gleixner <tglx@...utronix.de> wrote:
> > And those cleanups make the compiler generate worse code at least on
> > x86_64:
> >
> > text data bss dec hex filename
> > 7475 554 0 8029 1f5d kernel/hrtimer.o
> > 7706 554 0 8260 2044 kernel/hrtimer.o
> >
> > So just removing parameters and return values because you can get the
> > same information from a datastructure is not necessarily a good thing.
>
> Hmm.. Nice.
>
> Okay, I will have another look at patches and do this kind of investigation
> before sending it next time :) Its been fun going through these frameworks.
>
> How do you want to proceed now? I mean, you will take the other patches
> (which don't play with function parameters) as is or want me to send a single
> unified patchset with all the pending patches that I have?
I still want to go through the lot and review them, but I wont take
anything before the end of the merge window.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists