Re: [PATCH 2/3] mm: page allocator: Calculate a better estimate of NR_FREE_PAGES when memory is low and kswapd is awake

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

 



On Thu, Aug 19, 2010 at 5:06 PM, Mel Gorman <mel@xxxxxxxxx> wrote:
> On Wed, Aug 18, 2010 at 11:57:26PM +0900, Minchan Kim wrote:
>> On Wed, Aug 18, 2010 at 09:51:23AM +0100, Mel Gorman wrote:
>> > > What's a window low and min wmark? Maybe I can miss your point.
>> > >
>> >
>> > The window is due to the fact kswapd is not awake yet. The window is because
>> > kswapd might not be awake as NR_FREE_PAGES is higher than it should be. The
>> > system is really somewhere between the low and min watermark but we are not
>> > taking the accurate measure until kswapd gets woken up. The first allocation
>> > to notice we are below the low watermark (be it due to vmstat refreshing or
>> > that NR_FREE_PAGES happens to report we are below the watermark regardless of
>> > any drift) wakes kswapd and other callers then take an accurate count hence
>> > "we could breach the watermark but I'm expecting it can only happen for at
>> > worst one allocation".
>>
>> Right. I misunderstood your word.
>> One more question.
>>
>> Could you explain live lock scenario?
>>
>
> Lets say
>
> NR_FREE_PAGES     = 256
> Actual free pages = 8
>
> The PCP lists get refilled in patch taking all 8 pages. Now there are
> zero free pages. Reclaim kicks in but to reclaim any pages it needs to
> clean something but all the pages are on a network-backed filesystem. To
> clean them, it must transmit on the network so it tries to allocate some
> buffers.
>
> The livelock is that to free some memory, an allocation must succeed but
> for an allocation to succeed, some memory must be freed. The system

Yes. I understood this as livelock but at last VM will kill victim
process then it can allocate free pages.
So I think it's not a livelock.

> might still remain alive if a process exits and does not need to
> allocate memory while exiting but by and large, the system is in a
> dangerous state.

Do you mean dangerous state of the system is livelock?
Maybe not.
I can't understand livelock in this context.
Anyway, I am okay with this patch except livelock pharse. :)

Thanks, Mel.
-- 
Kind regards,
Minchan Kim

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]