[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54FED559.2030506@ti.com>
Date: Tue, 10 Mar 2015 13:28:25 +0200
From: Tomi Valkeinen <tomi.valkeinen@...com>
To: Thomas Niederprüm <niederp@...sik.uni-kl.de>,
Maxime Ripard <maxime.ripard@...e-electrons.com>
CC: <linux-fbdev@...r.kernel.org>, <plagnioj@...osoft.com>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/8] fbdev: ssd1307fb: Use vmalloc to allocate video memory.
On 14/02/15 16:22, Thomas Niederprüm wrote:
> Am Thu, 12 Feb 2015 16:11:21 +0100
> schrieb Maxime Ripard <maxime.ripard@...e-electrons.com>:
>
>> On Sat, Feb 07, 2015 at 04:35:41PM +0100, Thomas Niederprüm wrote:
>>> Am Sat, 7 Feb 2015 12:18:21 +0100
>>> schrieb Maxime Ripard <maxime.ripard@...e-electrons.com>:
>>>
>>>> Hi,
>>>>
>>>> On Fri, Feb 06, 2015 at 11:28:10PM +0100, niederp@...sik.uni-kl.de
>>>> wrote:
>>>>> From: Thomas Niederprüm <niederp@...sik.uni-kl.de>
>>>>>
>>>>> It makes sense to use vmalloc to allocate the video buffer
>>>>> since it has to be page aligned memory for using it with mmap.
>>>>
>>>> Please wrap your commit log at 80 chars.
>>>
>>> I'll try to do so in future, sorry for that.
>>>
>>>>
>>>> It looks like there's numerous fbdev drivers using this
>>>> (especially since you copy pasted that code, without mentionning
>>>> it).
>>>
>>> Yes, I should have mentioned that in the commit message. As
>>> implicitly indicated in the cover letter the rvmalloc() and
>>> rvfree() are copy pasted from the vfb driver. Honestly, I didn't
>>> give this one too much thought. It seemed a viable solution to the
>>> mmap problem. For a bit more history on that, see my comment below.
>>>
>>>>
>>>> That should be turned into an allocator so that drivers all get
>>>> this right.
>>>>
>>>>> Also deffered io seems buggy in combination with kmalloc'ed
>>>>> memory (crash on unloading the module).
>>>>
>>>> And maybe that's the real issue to fix.
>>>
>>> The problem is solved by using vmalloc ;)
>>
>> Yep, but why do you need to mark the reserved pages?
>>
>> ...
>
> As far as I understood mmaped memory is marked as userspace memory in
> the page table and is therefore subject to swapping. The pages are
> marked reserved to make clear that this memory can not be swapped and
> thus lock the pages in memory. See discussions [0,1,2].
Why is it a problem if it is swapped? Only CPU uses the memory, as far
as I can see.
Also, isn't doing __pa() for the memory returned by vmalloc plain wrong?
What was the crash about when using kmalloc? It would be good to fix
defio, as I don't see why it should not work with kmalloced memory.
Tomi
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists