Andrew,
On Wed, Sep 26, 2012 at 6:42 PM, Andrew Morton
wrote:
> On Tue, 25 Sep 2012 22:15:38 -0300
> Ezequiel Garcia wrote:
>
>> > This patch increases util.o's text size by 238 bytes. A larger kernel
>> > with a worsened cache footprint.
>> >
>> > And we did this to get marginally improved
On Tue, 25 Sep 2012 22:15:38 -0300
Ezequiel Garcia wrote:
> > This patch increases util.o's text size by 238 bytes. A larger kernel
> > with a worsened cache footprint.
> >
> > And we did this to get marginally improved tracing output? This sounds
> > like a bad tradeoff to me.
> >
>
> Mmm,
On Tue, 25 Sep 2012 22:15:38 -0300
Ezequiel Garcia elezegar...@gmail.com wrote:
This patch increases util.o's text size by 238 bytes. A larger kernel
with a worsened cache footprint.
And we did this to get marginally improved tracing output? This sounds
like a bad tradeoff to me.
Andrew,
On Wed, Sep 26, 2012 at 6:42 PM, Andrew Morton
a...@linux-foundation.org wrote:
On Tue, 25 Sep 2012 22:15:38 -0300
Ezequiel Garcia elezegar...@gmail.com wrote:
This patch increases util.o's text size by 238 bytes. A larger kernel
with a worsened cache footprint.
And we did
Hi Andrew,
On Tue, Sep 25, 2012 at 6:29 PM, Andrew Morton
wrote:
> On Sat, 8 Sep 2012 17:47:54 -0300
> Ezequiel Garcia wrote:
>
>> Previously the strndup_user allocation was being done through memdup_user,
>> and the caller was wrongly traced as being strndup_user
>> (the correct trace must
On Sat, 8 Sep 2012 17:47:54 -0300
Ezequiel Garcia wrote:
> Previously the strndup_user allocation was being done through memdup_user,
> and the caller was wrongly traced as being strndup_user
> (the correct trace must report the caller of strndup_user).
>
> This is a common problem: in order
On Sat, Sep 8, 2012 at 11:47 PM, Ezequiel Garcia wrote:
> Previously the strndup_user allocation was being done through memdup_user,
> and the caller was wrongly traced as being strndup_user
> (the correct trace must report the caller of strndup_user).
>
> This is a common problem: in order to
On Sat, Sep 8, 2012 at 11:47 PM, Ezequiel Garcia elezegar...@gmail.com wrote:
Previously the strndup_user allocation was being done through memdup_user,
and the caller was wrongly traced as being strndup_user
(the correct trace must report the caller of strndup_user).
This is a common
On Sat, 8 Sep 2012 17:47:54 -0300
Ezequiel Garcia elezegar...@gmail.com wrote:
Previously the strndup_user allocation was being done through memdup_user,
and the caller was wrongly traced as being strndup_user
(the correct trace must report the caller of strndup_user).
This is a common
Hi Andrew,
On Tue, Sep 25, 2012 at 6:29 PM, Andrew Morton
a...@linux-foundation.org wrote:
On Sat, 8 Sep 2012 17:47:54 -0300
Ezequiel Garcia elezegar...@gmail.com wrote:
Previously the strndup_user allocation was being done through memdup_user,
and the caller was wrongly traced as being
Previously the strndup_user allocation was being done through memdup_user,
and the caller was wrongly traced as being strndup_user
(the correct trace must report the caller of strndup_user).
This is a common problem: in order to get accurate callsite tracing,
a utils function can't allocate
Previously the strndup_user allocation was being done through memdup_user,
and the caller was wrongly traced as being strndup_user
(the correct trace must report the caller of strndup_user).
This is a common problem: in order to get accurate callsite tracing,
a utils function can't allocate
12 matches
Mail list logo