[LITMUS^RT] RFP: Jumbo Ring Buffers

[Glenn Elliott]

Wow! I'm glad to see so few code changes were necessary.  I'll give the
code a spin this weekend.  This will really help in experimentation.


On Thu, May 30, 2013 at 5:44 AM, Björn Brandenburg <bbb at mpi-sws.org> wrote:

> On Apr 23, 2013, at 6:18 PM, Christopher Kenna <cjk at cs.unc.edu> wrote:
>
> On Mon, Apr 22, 2013 at 11:55 PM, Björn Brandenburg <bbb at mpi-sws.org>
> wrote:
>
> Thanks a lot for the pointers! How about this function?
>
>        http://lxr.linux.no/linux+v3.0/mm/vmalloc.c#L1680
>
> From the inline documentation, it doesn't sound like there's a limit on
> the maximum vmalloc() allocation. We don't care whether it is expensive or
> not; it's a one-time thing anyways.
>
>
> I'm no expert, but it seems reasonable. It looks like it does
> something similar (eventually calling map_vm_area, like the other
> function), but also calls kzalloc/kmalloc so that you don't have to
> worry about allocating/tracking your own pages. Glenn might be
> interested in the 'node' parameter, too.
>
>
> I've coded this up. Please have a look at commit
>
>
> https://github.com/LITMUS-RT/litmus-rt/commit/3ffc3fca3bc90d0603454ce3a7f3d3af50d74aab
>
> in branch prop/large-trace-buffers.
>
> I've done some small-scale testing in KVM and it seems to work. Glenn,
> please give it a try if you get a chance.
>
> Thanks,
> Björn
>
>
> _______________________________________________
> litmus-dev mailing list
> litmus-dev at lists.litmus-rt.org
> https://lists.litmus-rt.org/listinfo/litmus-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20130531/383394ee/attachment.html>