Added CONFIG_COMPACTION=y to defconfigs

[Ferroin]

This adds a slight overhead to memory allocation (maybe 2us without
overclocking), but improves preformance with workloads that use a lot of
big blocks of memory. It might also (theoretically) improve behavior
with respect to issues like #153, I've had such problems less frequently on
kernels with this set.

[popcornmix]

@P33M any thoughts?

[P33M]

That was one option that was on my to-do list to test. We need to get some testing input from people actually seeing this error though - if we are doing an atomic allocation then the delay can be a bit big... uvcvideo in particular is a bad offender for this because it will request a rather large coherent range for its URBs.

[Ferroin]

Well, as I said, i personally see the error less with this enabled. With this enabled I get errors like #153 maybe once a week, as opposed to roughly once a day without it enabled.

[popcornmix]

Just noticed that CONFIG_COMPACTION is enabled in 3.9.y kernel tree (and so branch=next firmware), so I guess it doesn't have any widespread bad effect.

[Ferroin]

Just finished some intensive profiling, with this enabled malloc() is ~5us slower in most cases, except when memory is almost full and the request will fit in memory, in which case it is marginally faster because the kernel can compact memory to make a large enough space for the request, as opposed to either killing something or paging to disk.

[popcornmix]

@Ferroin
So what's your view? Is the 5us a problem?
How long does memory allocation normally take? How many allocations/sec are you seeing?

[Ferroin]

Outside of realtime use cases, 5us is probably not a problem; even then it might not be depending on how the program is written (ie, if it allocates all it's memory on startup, instead of allocating on the fly, this will have less impact).

As for the 'normal' time that allocation takes, it can vary hugely depending on a large number of factors. In general, any dynamic allocation (eg malloc(), free(), calloc(), kmalloc() etc.) is going to be slow (on the order of at least 100us). The 5us figure is based on more than ten thousand samples taken over a few days during a wide variety of system states. The overall biggest increase was almost 2ms when it was the only userspace process running, but this is major outlier, most of the samples were in the range of about +13us to -6us difference with this option on. To do the actual testing, i used profiling on the following generic program:

for (int i; i < 600; i++) {
    sleep_1_second()
    mem = malloc(random_multiple_of_4096)
    sleep_1_second()
    free(mem)
}

As for the number of allocations per second, this is largely dependent on what programs you are using. In general, stuff that has very well defined memory usage, such as most of the GNU coreutils (with the big exception of dd) and a large majority of emulation software, will show fewer allocations per second. Simulations, games, and media software tend to have much higher allocation rates, but usually only in large bursts.

[popcornmix]

Obviously an increase of 5us for a function that is called 100,000 times per second would be a big problem.
If it's called, less than 1000 times per second, then it would be hard to measure the impact.

Does this just apply to user malloc, or kmallocs? Can the usb or network kernel drivers cause many allocation per second?

[P33M]

kmalloc is my biggest concern. dwc_otg in particular is very kmalloc-happy, which it mainly does with interrupts disabled.

Other kernel drivers may disable interrupts to do kmallocs (though this is rarer - they are usually sensibly written).

I did profile the URB enqueue function to determine its critical section time - there are two potential kmalloc calls within this, and the whole section usually takes 4uS. If we add 5uS to each - then it's a big deal.

As established previously, the USB subsystem is very sensitive to something disabling interrupts for more than a microframe's worth of time. I have a feeling that some high-bandwidth audio/video USB driver will do something silly with allocation, and with the added delay may cause problems.

[Ferroin]

I'll rebuild my kernel with the appropriate options to check if it has a big effect on kmalloc and get back to you on it.

Even aside from this, if dwc_otg uses kmalloc a lot with interrupts off, that probably explains a lot of the USB multimedia problems, and possibly also the input latency problems some of my friends have seen.

[Ferroin]

Just finished re building the kernel, I'll do some intensive testing both with and without CONFIG_COMPACTION=y.

Peraonally, I haven't had any problems up to this point using a kernel with CONFIG_COMPACTION set, but then my only USB traffic is infrequent NFS and SSH network connections.

[P33M]

We had a real-world use case unrelated to USB that benefited from this, as Rob and I found yesterday.

Extracting an xz-compressed tar on the SD card and then writing to the same SD card sped up by about a factor of 2.

As CONFIG_COMPACTION seems to squash the majority of allocation failures (and pesky kevent 2 spam), with a small static penalty for small allocations that require a compaction event, I recommend including it. I define "small" as "not a significant fraction of a USB microframe", which is the critical timing parameter for holding off interrupts.

I did some basic regression testing with a USB webcam - the poster child for testing interrupt holdoffs - with this enabled it seems that guvcview complains less about running out of space for its buffers, which is good. The webcam was still useable.

I would also recommend changing the memory allocator to SLUB for an added performance benefit. I think Arch has been using this as the default in their kernels for some time now.

[Ferroin]

I've also found NFS to be faster with this enabled (makes it more likely that a buffer allocation will be contiguous).

[popcornmix]

@P33M
Just to confirm. Remove SLAB and add SLUB?
SLUB_DEBUG? SLUB_STATS?

[P33M]

Remove CONFIG_SLAB=y
Add CONFIG_SLUB=y
Add CONFIG_SLUB_DEBUG=y - adds to compiled code size, but defaults to all features being turned off therefore has a very minimal impact on speed.

See http://www.mail-archive.com/git-commits-head@vger.kernel.org/msg12389.html

Kernel docs say to leave SLUB_STATS turned off for production use (it profiles the allocator).

[popcornmix]

Thanks. That's what I'm building with. If I don't spot any obvious problems I'll push out an update with these options this weekend.

[popcornmix]

CONFIG_COMPACTION and CONFIG_SLUB options have been committed.
@Ferroin thanks for the suggestion.