linux-kernel - Re: long sleep_on_page delays writing to slow storage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20111109180646.GM5075@redhat.com>
Date:	Wed, 9 Nov 2011 19:06:46 +0100
From:	Andrea Arcangeli <aarcange@...hat.com>
To:	Mel Gorman <mgorman@...e.de>
Cc:	Jan Kara <jack@...e.cz>, Andy Isaacson <adi@...apodia.org>,
	linux-kernel@...r.kernel.org, linux-mm@...r.kernel.org,
	Johannes Weiner <jweiner@...hat.com>
Subject: Re: long sleep_on_page delays writing to slow storage

On Wed, Nov 09, 2011 at 05:52:01PM +0000, Mel Gorman wrote:
> -#define alloc_pages_vma(gfp_mask, order, vma, addr, node)	\
> -	alloc_pages(gfp_mask, order)
> +#define alloc_pages_vma(gfp_mask, order, vma, addr, node, drop_mmapsem)	\
> +	({ 								\
> +		if (drop_mmapsem)					\
> +			up_read(&vma->vm_mm->mmap_sem);			\
> +		alloc_pages(gfp_mask, order);				\
> +	})

I wouldn't change alloc_pages_vma. I think it's better to add and have
that called only by khugepaged:

alloc_pages_vma_up_read(gfp_mask, order, vma, addr, node)
{
	__alloc_pages_vma(gfp_mask, order, vma, addr, node, true);
}

alloc_pages_vma(gfp_mask, order, vma, addr, node)
{
	__alloc_pages_vma(gfp_mask, order, vma, addr, node, false);
}

I wonder if a change like this would be enough?

       sync_migration = !(gfp_mask & __GFP_NO_KSWAPD);

But even if hidden in a new function, the main downside overall is the
fact we'll pass one more var through the stack of fast paths.

Johannes I recall you reported this too and Mel suggested the above
change, did it help in the end?

Your change in khugepaged context makes perfect sense anyway, just we
should be sure it's really needed before adding more variables in fast
path I think.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/