I understand that you are maintaining the page blocks in region sorted order. So that way, when the memory requests come in, you can hand out memory from the regions in that order. However, do you take this scenario into account - in some bucket of the buddy allocator, there might not be any pages belonging to, lets say, region 0, while the next higher bucket has them. So, instead of handing out memory from whichever region thats present there, to probably go to the next bucket and split that region 0 pageblock there and allocate from it ? (Here, region 0 is just an example). Been a while since I looked at kernel code, so I might be missing something!
Regards,
Ankita
On Wed, Nov 7, 2012 at 2:15 PM, Srivatsa S. Bhat <srivatsa.bhat@xxxxxxxxxxxxxxxxxx> wrote:
As I mentioned in the cover-letter, kernbench numbers haven't shown anyOn 11/07/2012 03:19 AM, Dave Hansen wrote:
> On 11/06/2012 11:53 AM, Srivatsa S. Bhat wrote:
>> This is the main change - we keep the pageblocks in region-sorted order,
>> where pageblocks belonging to region-0 come first, followed by those belonging
>> to region-1 and so on. But the pageblocks within a given region need *not* be
>> sorted, since we need them to be only region-sorted and not fully
>> address-sorted.
>>
>> This sorting is performed when adding pages back to the freelists, thus
>> avoiding any region-related overhead in the critical page allocation
>> paths.
>
> It's probably _better_ to do it at free time than alloc, but it's still
> pretty bad to be doing a linear walk over a potentially 256-entry array
> holding the zone lock. The overhead is going to show up somewhere. How
> does this do with a kernel compile? Looks like exit() when a process
> has a bunch of memory might get painful.
>
observable performance degradation. On the contrary, (as unbelievable as it
may sound), they actually indicate a slight performance *improvement* with my
patchset! I'm trying to figure out what could be the reason behind that.
Going forward, we could try to optimize the sorting logic in the free()
part, but in any case, IMHO that's the right place to push the overhead to,
since the performance of free() is not expected to be _that_ critical (unlike
alloc()) for overall system performance.
Regards,
Srivatsa S. Bhat
Regards,
Ankita
Graduate Student
Department of Computer Science
University of Texas at Austin