Re: [virtio-dev] Re: [PATCH v13 4/5] mm: support reporting free page blocks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu 10-08-17 15:38:34, Wei Wang wrote:
> On 08/10/2017 03:05 PM, Michal Hocko wrote:
> >On Tue 08-08-17 14:34:25, Wei Wang wrote:
> >>On 08/08/2017 02:12 PM, Wei Wang wrote:
> >>>On 08/03/2017 05:11 PM, Michal Hocko wrote:
> >>>>On Thu 03-08-17 14:38:18, Wei Wang wrote:
> >>>>This is just too ugly and wrong actually. Never provide struct page
> >>>>pointers outside of the zone->lock. What I've had in mind was to simply
> >>>>walk free lists of the suitable order and call the callback for each
> >>>>one.
> >>>>Something as simple as
> >>>>
> >>>>    for (i = 0; i < MAX_NR_ZONES; i++) {
> >>>>        struct zone *zone = &pgdat->node_zones[i];
> >>>>
> >>>>        if (!populated_zone(zone))
> >>>>            continue;
> >>>Can we directly use for_each_populated_zone(zone) here?
> >yes, my example couldn't because I was still assuming per-node API
> >
> >>>>spin_lock_irqsave(&zone->lock, flags);
> >>>>        for (order = min_order; order < MAX_ORDER; ++order) {
> >>>
> >>>This appears to be covered by for_each_migratetype_order(order, mt) below.
> >yes but
> >#define for_each_migratetype_order(order, type) \
> >	for (order = 0; order < MAX_ORDER; order++) \
> >		for (type = 0; type < MIGRATE_TYPES; type++)
> >
> >so you would have to skip orders < min_order
> 
> Yes, that's why we have a new macro
> 
> #define for_each_migratetype_order_decend(min_order, order, type) \
>  for (order = MAX_ORDER - 1; order < MAX_ORDER && order >= min_order; \
>  order--) \
>     for (type = 0; type < MIGRATE_TYPES; type++)
> 
> If you don't like the macro, we can also directly use it in the code.
> 
> I think it would be better to report the larger free page block first, since
> the callback has an opportunity (though just a theoretical possibility, good
> to
> take that into consideration if possible) to skip reporting the given free
> page
> block to the hypervisor as the ring gets full. Losing the small block is
> better
> than losing the larger one, in terms of the optimization work.

I see. But I think this is so specialized that opencoding the macro
would be easier to read.

-- 
Michal Hocko
SUSE Labs



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux