linux-kernel - Re: [RFC PATCH] ARM: mm: disable kmap_high

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: <CAAmzW4NjefPV7tryvySfLXPy6Zcz3BLTvfxD=UnTKCqrRB3voQ@mail.gmail.com>
Date:	Thu, 7 Mar 2013 19:35:51 +0900
From:	JoonSoo Kim <js1304@...il.com>
To:	Nicolas Pitre <nicolas.pitre@...aro.org>
Cc:	Joonsoo Kim <iamjoonsoo.kim@....com>,
	Russell King <linux@....linux.org.uk>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] ARM: mm: disable kmap_high_get() for SMP

2013/3/7 Nicolas Pitre <nicolas.pitre@...aro.org>:
> On Thu, 7 Mar 2013, Joonsoo Kim wrote:
>
>> Hello, Nicolas.
>>
>> On Tue, Mar 05, 2013 at 05:36:12PM +0800, Nicolas Pitre wrote:
>> > On Mon, 4 Mar 2013, Joonsoo Kim wrote:
>> >
>> > > With SMP and enabling kmap_high_get(), it makes users of kmap_atomic()
>> > > sequential ordered, because kmap_high_get() use global kmap_lock().
>> > > It is not welcome situation, so turn off this optimization for SMP.
>> >
>> > I'm not sure I understand the problem.
>> >
>> > The lock taken by kmap_high_get() is released right away before that
>> > function returns and therefore this is not actually serializing
>> > anything.
>>
>> Yes, you understand what I want to say correctly.
>> Sorry for bad explanation.
>>
>> Following is reasons why I send this patch with RFC tag.
>>
>> If we have more cpus, performance degration is possible although
>> it is very short time to holding the lock in kmap_high_get().
>>
>> And kmap has maximum 512 entries(512 * 4K = 2M) and some mobile devices
>> has 2G memory(highmem 1G>), so probability for finding matched entry
>> is approximately < 1/512. This probability can be more decreasing
>> for device which have more memory. So I think that waste time to find
>> matched entry is more than saved time.
>>
>> Above is my humble opinion, so please let me know what I am missing.
>
> Please look at the kmap_high_get() code again.  It performs no
> searching at all.  What it does is:

If page is not highmem, it may be already filtered in kmap_atomic().
So we only consider highmem page.

For highmem page, it perform searching.
In kmap_high_get(), page_address() is called.
In page_address(), it hash PA and iterate a list for this hashed value.

And another advantage of disabling ARCH_NEEDS_KMAP_HIGH_GET is
that kmap(), kunmap() works without irq disabled.

Thanks.

> - lock the kmap array against concurrent changes
>
> - if the given page is not highmem, unlock and return NULL
>
> - otherwise increment that page reference count, unlock, and return the
>   mapped address for that page.
>
> There is almost zero cost to this function, independently of the number
> of kmap entries, whereas it does save much bigger costs elsewhere when
> it is successful.
>
>
> Nicolas
> --
> 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/
--
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/