Hi Andi, Andreas,
Thanks for comments.
On 12/30/2014 10:29 PM, Andi Kleen wrote:
>> This symmetry issue probably could be cleanly avoided only
>> by having kfree() itself contain such an identifying check, as you suggest
>> (thereby slowing down kfree() performance).
>
> It actually shouldn't
Hi Andi, Andreas,
Thanks for comments.
On 12/30/2014 10:29 PM, Andi Kleen wrote:
This symmetry issue probably could be cleanly avoided only
by having kfree() itself contain such an identifying check, as you suggest
(thereby slowing down kfree() performance).
It actually shouldn't slow it
On 12/29/2014 03:48 PM, Andrzej Hajda wrote:
(...)
> As I have tested it on mobile platform (exynos4210-trats) it saves above 2600
> string duplications. Below simple stats about the most frequent duplications:
> Count String
> 880 power
> 874 subsystem
> 130 device
> 126 parameters
>
On 12/29/2014 03:48 PM, Andrzej Hajda wrote:
(...)
As I have tested it on mobile platform (exynos4210-trats) it saves above 2600
string duplications. Below simple stats about the most frequent duplications:
Count String
880 power
874 subsystem
130 device
126 parameters
61
> This symmetry issue probably could be cleanly avoided only
> by having kfree() itself contain such an identifying check, as you suggest
> (thereby slowing down kfree() performance).
It actually shouldn't slow it down. kfree already complains if you free
a non slab page, this could be just in
Hi,
Andrzej Hajda wrote:
> On 12/30/2014 07:45 AM, Andi Kleen wrote:
> > What happens if someone is to kfree() these strings?
> >
> > -Andi
> >
> kstrdup_const must be accompanied by kfree_const, I did not mention it
> in cover letter
> but it is described in the 1st patch commit message.
>
Hi,
Andrzej Hajda wrote:
On 12/30/2014 07:45 AM, Andi Kleen wrote:
What happens if someone is to kfree() these strings?
-Andi
kstrdup_const must be accompanied by kfree_const, I did not mention it
in cover letter
but it is described in the 1st patch commit message.
Simpler
This symmetry issue probably could be cleanly avoided only
by having kfree() itself contain such an identifying check, as you suggest
(thereby slowing down kfree() performance).
It actually shouldn't slow it down. kfree already complains if you free
a non slab page, this could be just in front
On 12/30/2014 07:45 AM, Andi Kleen wrote:
> Andrzej Hajda writes:
>
>> kstrdup if often used to duplicate strings where neither source neither
>> destination will be ever modified. In such case we can just reuse the source
>> instead of duplicating it. The problem is that we must be sure that
>>
Andrzej Hajda writes:
> kstrdup if often used to duplicate strings where neither source neither
> destination will be ever modified. In such case we can just reuse the source
> instead of duplicating it. The problem is that we must be sure that
> the source is non-modifiable and its life-time is
Hi,
kstrdup if often used to duplicate strings where neither source neither
destination will be ever modified. In such case we can just reuse the source
instead of duplicating it. The problem is that we must be sure that
the source is non-modifiable and its life-time is long enough.
I suspect
Hi,
kstrdup if often used to duplicate strings where neither source neither
destination will be ever modified. In such case we can just reuse the source
instead of duplicating it. The problem is that we must be sure that
the source is non-modifiable and its life-time is long enough.
I suspect
Andrzej Hajda a.ha...@samsung.com writes:
kstrdup if often used to duplicate strings where neither source neither
destination will be ever modified. In such case we can just reuse the source
instead of duplicating it. The problem is that we must be sure that
the source is non-modifiable and
On 12/30/2014 07:45 AM, Andi Kleen wrote:
Andrzej Hajda a.ha...@samsung.com writes:
kstrdup if often used to duplicate strings where neither source neither
destination will be ever modified. In such case we can just reuse the source
instead of duplicating it. The problem is that we must be
14 matches
Mail list logo
