---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
On Fri, 2009-04-03 at 16:43 +0200, [email protected] wrote:
> Index: b/include/linux/mm.h
> ===================================================================
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -13,6 +13,7 @@
> #include <linux/prio_tree.h>
> #include <linux/debug_locks.h>
> #include <linux/mm_types.h>
> +#include <linux/sched.h>
Why do we need that new include?
> struct mempolicy;
> struct anon_vma;
> @@ -1318,6 +1319,6 @@ void vmemmap_populate_print_last(void);
>
> extern void *alloc_locked_buffer(size_t size);
> extern void free_locked_buffer(void *buffer, size_t size);
> -extern void release_locked_buffer(void *buffer, size_t size);
> +extern void refund_locked_buffer_memory(struct mm_struct *mm, size_t size);
that's a pointer to a struct, so it doesn't need a fully qualified type.
Also, I can't say I like the name, what about something like:
void account_locked_buffer(struct mm_struct *mm, long pages)
{
down_write(&mm->mmap_sem);
mm->total_vm += pages;
mm->locked_vm += pages;
up_write(&mm->mmap_sem);
}
but looking more closely at that alloc_locked_buffer() stuff, I really
hate it, who in his right mind does a multi-page kmalloc() -- that's
crazy.
>-----Original Message-----
>From: Peter Zijlstra [mailto:[email protected]]
>Sent: Friday, April 03, 2009 5:01 PM
>To: Metzger, Markus T
>Also, I can't say I like the name, what about something like:
>
>void account_locked_buffer(struct mm_struct *mm, long pages)
>{
> down_write(&mm->mmap_sem);
>
> mm->total_vm += pages;
> mm->locked_vm += pages;
>
> up_write(&mm->mmap_sem);
>}
>
>but looking more closely at that alloc_locked_buffer() stuff, I really
>hate it, who in his right mind does a multi-page kmalloc() -- that's
>crazy.
I need a non-pageable chunk of memory to give to the cpu to store branch
trace data in. Kmalloc() is easy to use and gives me what I need.
How would I do this correctly?
thanks,
markus.
---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
On Sat, 2009-04-04 at 08:17 +0100, Metzger, Markus T wrote:
> >-----Original Message-----
> >From: Peter Zijlstra [mailto:[email protected]]
> >Sent: Friday, April 03, 2009 5:01 PM
> >To: Metzger, Markus T
>
>
> >Also, I can't say I like the name, what about something like:
> >
> >void account_locked_buffer(struct mm_struct *mm, long pages)
> >{
> > down_write(&mm->mmap_sem);
> >
> > mm->total_vm += pages;
> > mm->locked_vm += pages;
> >
> > up_write(&mm->mmap_sem);
> >}
> >
> >but looking more closely at that alloc_locked_buffer() stuff, I really
> >hate it, who in his right mind does a multi-page kmalloc() -- that's
> >crazy.
>
> I need a non-pageable chunk of memory to give to the cpu to store branch
> trace data in. Kmalloc() is easy to use and gives me what I need.
>
> How would I do this correctly?
Well, how large should this buffer be and must it be physically
contiguous?
Apparently its large enough to account in pages, that would suggest you
should use the page allocator to get memory.
Furthermore, if it needs to be physically contiguous and its more than
say 8 pages worth, you're basically up shit creek.
>-----Original Message-----
>From: Peter Zijlstra [mailto:[email protected]]
>Sent: Saturday, April 04, 2009 1:13 PM
>To: Metzger, Markus T
>Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected];
>[email protected]; [email protected]; Villacis, Juan; [email protected]; linux-
>[email protected]; Andrew Morton
>Subject: RE: [patch 03/20] x86, ptrace, bts: defer branch trace stopping
>
>On Sat, 2009-04-04 at 08:17 +0100, Metzger, Markus T wrote:
>> >-----Original Message-----
>> >From: Peter Zijlstra [mailto:[email protected]]
>> >Sent: Friday, April 03, 2009 5:01 PM
>> >To: Metzger, Markus T
>>
>>
>> >Also, I can't say I like the name, what about something like:
>> >
>> >void account_locked_buffer(struct mm_struct *mm, long pages)
>> >{
>> > down_write(&mm->mmap_sem);
>> >
>> > mm->total_vm += pages;
>> > mm->locked_vm += pages;
>> >
>> > up_write(&mm->mmap_sem);
>> >}
>> >
>> >but looking more closely at that alloc_locked_buffer() stuff, I really
>> >hate it, who in his right mind does a multi-page kmalloc() -- that's
>> >crazy.
>>
>> I need a non-pageable chunk of memory to give to the cpu to store branch
>> trace data in. Kmalloc() is easy to use and gives me what I need.
>>
>> How would I do this correctly?
>
>Well, how large should this buffer be and must it be physically
>contiguous?
The size is set by the user. It is limited by (locked memory) RLIMIT.
The buffer need not be physically contiguous, but it must not be paged out
and should be marked accessed and dirty.
(see ?18.7.8.2 in vol. 3b, Software Developer's Manual).
>Apparently its large enough to account in pages, that would suggest you
>should use the page allocator to get memory.
Wouldn't kmalloc forward the request to the page allocator for large memory?
>Furthermore, if it needs to be physically contiguous and its more than
>say 8 pages worth, you're basically up shit creek.
If not enough memory is available, I would expect users to request smaller
buffers until the request can be satisfied.
thanks and regards,
markus.
---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
On Tue, 2009-04-07 at 09:12 +0100, Metzger, Markus T wrote:
> >-----Original Message-----
> >From: Peter Zijlstra [mailto:[email protected]]
> >Sent: Saturday, April 04, 2009 1:13 PM
> >To: Metzger, Markus T
> >Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected];
> >[email protected]; [email protected]; Villacis, Juan; [email protected]; linux-
> >[email protected]; Andrew Morton
> >Subject: RE: [patch 03/20] x86, ptrace, bts: defer branch trace stopping
> >
> >On Sat, 2009-04-04 at 08:17 +0100, Metzger, Markus T wrote:
> >> >-----Original Message-----
> >> >From: Peter Zijlstra [mailto:[email protected]]
> >> >Sent: Friday, April 03, 2009 5:01 PM
> >> >To: Metzger, Markus T
> >>
> >>
> >> >Also, I can't say I like the name, what about something like:
> >> >
> >> >void account_locked_buffer(struct mm_struct *mm, long pages)
> >> >{
> >> > down_write(&mm->mmap_sem);
> >> >
> >> > mm->total_vm += pages;
> >> > mm->locked_vm += pages;
> >> >
> >> > up_write(&mm->mmap_sem);
> >> >}
> >> >
> >> >but looking more closely at that alloc_locked_buffer() stuff, I really
> >> >hate it, who in his right mind does a multi-page kmalloc() -- that's
> >> >crazy.
> >>
> >> I need a non-pageable chunk of memory to give to the cpu to store branch
> >> trace data in. Kmalloc() is easy to use and gives me what I need.
> >>
> >> How would I do this correctly?
> >
> >Well, how large should this buffer be and must it be physically
> >contiguous?
>
> The size is set by the user. It is limited by (locked memory) RLIMIT.
>
> The buffer need not be physically contiguous, but it must not be paged out
> and should be marked accessed and dirty.
> (see §18.7.8.2 in vol. 3b, Software Developer's Manual).
The Intel one I presume?
Ok, if you must mark the pages accessed and dirty you should get whole
pages, otherwise you cannot make that promise on the ptes, right?
> >Apparently its large enough to account in pages, that would suggest you
> >should use the page allocator to get memory.
>
> Wouldn't kmalloc forward the request to the page allocator for large memory?
It may, but doesn't need to.
> >Furthermore, if it needs to be physically contiguous and its more than
> >say 8 pages worth, you're basically up shit creek.
>
> If not enough memory is available, I would expect users to request smaller
> buffers until the request can be satisfied.
Sounds like a very bad interface, esp since you don't need physically
contiguous memory.
So what you need to do is allocate pages, order-0, grab a reference,
then vmap them into a linear piece, poke at the ptes to set the young
and dirty bits and provide that to your hardware.
>-----Original Message-----
>From: Peter Zijlstra [mailto:[email protected]]
>Sent: Tuesday, April 07, 2009 10:29 AM
>To: Metzger, Markus T
>Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected];
>[email protected]; [email protected]; Villacis, Juan; [email protected]; linux-
>[email protected]; Andrew Morton
>Subject: RE: [patch 03/20] x86, ptrace, bts: defer branch trace stopping
>
>On Tue, 2009-04-07 at 09:12 +0100, Metzger, Markus T wrote:
>> >-----Original Message-----
>> >From: Peter Zijlstra [mailto:[email protected]]
>> >Sent: Saturday, April 04, 2009 1:13 PM
>> >To: Metzger, Markus T
>> >Cc: [email protected]; [email protected]; [email protected]; [email protected];
>[email protected];
>> >[email protected]; [email protected]; Villacis, Juan; [email protected]; linux-
>> >[email protected]; Andrew Morton
>> >Subject: RE: [patch 03/20] x86, ptrace, bts: defer branch trace stopping
>> >
>> >On Sat, 2009-04-04 at 08:17 +0100, Metzger, Markus T wrote:
>> >> >-----Original Message-----
>> >> >From: Peter Zijlstra [mailto:[email protected]]
>> >> >Sent: Friday, April 03, 2009 5:01 PM
>> >> >To: Metzger, Markus T
>> >>
>> >>
>> >> >Also, I can't say I like the name, what about something like:
>> >> >
>> >> >void account_locked_buffer(struct mm_struct *mm, long pages)
>> >> >{
>> >> > down_write(&mm->mmap_sem);
>> >> >
>> >> > mm->total_vm += pages;
>> >> > mm->locked_vm += pages;
>> >> >
>> >> > up_write(&mm->mmap_sem);
>> >> >}
>> >> >
>> >> >but looking more closely at that alloc_locked_buffer() stuff, I really
>> >> >hate it, who in his right mind does a multi-page kmalloc() -- that's
>> >> >crazy.
>> >>
>> >> I need a non-pageable chunk of memory to give to the cpu to store branch
>> >> trace data in. Kmalloc() is easy to use and gives me what I need.
>> >>
>> >> How would I do this correctly?
>> >
>> >Well, how large should this buffer be and must it be physically
>> >contiguous?
>>
>> The size is set by the user. It is limited by (locked memory) RLIMIT.
>>
>> The buffer need not be physically contiguous, but it must not be paged out
>> and should be marked accessed and dirty.
>> (see §18.7.8.2 in vol. 3b, Software Developer's Manual).
>
>The Intel one I presume?
Yes. For x86 Architecture.
>Ok, if you must mark the pages accessed and dirty you should get whole
>pages, otherwise you cannot make that promise on the ptes, right?
The feedback I got so far was that kmalloc'ed memory is OK to use
in that case.
>> >Apparently its large enough to account in pages, that would suggest you
>> >should use the page allocator to get memory.
>>
>> Wouldn't kmalloc forward the request to the page allocator for large memory?
>
>It may, but doesn't need to.
>
>> >Furthermore, if it needs to be physically contiguous and its more than
>> >say 8 pages worth, you're basically up shit creek.
>>
>> If not enough memory is available, I would expect users to request smaller
>> buffers until the request can be satisfied.
>
>Sounds like a very bad interface, esp since you don't need physically
>contiguous memory.
>
>So what you need to do is allocate pages, order-0, grab a reference,
>then vmap them into a linear piece, poke at the ptes to set the young
>and dirty bits and provide that to your hardware.
OK.
Would a simple vmalloc() do the job?
Looks like it uses PAGE_KERNEL which has the present, accessed, and dirty bits
set. It also does the page allocation and vmap() for me.
thanks,
markus.
---------------------------------------------------------------------Intel GmbHDornacher Strasse 185622 Feldkirchen/Muenchen GermanySitz der Gesellschaft: Feldkirchen bei MuenchenGeschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes SchwadererRegistergericht: Muenchen HRB 47456 Ust.-IdNr.VAT Registration No.: DE129385895Citibank Frankfurt (BLZ 502 109 00) 600119052
This e-mail and any attachments may contain confidential material forthe sole use of the intended recipient(s). Any review or distributionby others is strictly prohibited. If you are not the intendedrecipient, please contact the sender and delete all copies.????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?