On Tue, Mar 09, 2021 at 04:53:48PM +0100, Christoph Hellwig wrote:
> Just use the generic anon_inode file system.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Minchan Kim
___
dri-devel mailing list
dri-devel@lists.freedesktop.
On Tue, Mar 09, 2021 at 04:53:40PM +0100, Christoph Hellwig wrote:
> Rename alloc_inode to free the name for a new variant that does not
> need boilerplate to create a super_block first.
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/powerpc/platforms/pseries/cmm.c | 2 +-
>
devel/2018-October/127519.html
> (sorry, could not find lore links for these discussions)
>
> Suggested-by: Laura Abbott
> Signed-off-by: Suren Baghdasaryan
Reviewed-by: Minchan Kim
A note: This patch makes dmabuf system heap accounted as PSS so
if someone has relies on the size, the
On Tue, Feb 02, 2021 at 04:31:33PM -0800, Suren Baghdasaryan wrote:
> Replace BUG_ON(vma->vm_flags & VM_PFNMAP) in vm_insert_page with
> WARN_ON_ONCE and returning an error. This is to ensure users of the
> vm_insert_page that set VM_PFNMAP are notified of the wrong flag usage
> and get an
On Thu, Jan 28, 2021 at 09:52:59AM -0800, Suren Baghdasaryan wrote:
> On Thu, Jan 28, 2021 at 1:13 AM Christoph Hellwig wrote:
> >
> > On Thu, Jan 28, 2021 at 12:38:17AM -0800, Suren Baghdasaryan wrote:
> > > Currently system heap maps its buffers with VM_PFNMAP flag using
> > > remap_pfn_range.
On Mon, Sep 21, 2020 at 08:17:08PM +0200, Christoph Hellwig wrote:
> On Mon, Sep 21, 2020 at 10:42:56AM -0700, Minchan Kim wrote:
> > IIRC, the problem was runtime pte popluating needs GFP_KERNEL but
> > zs_map_object API runs under non-preemtible section.
>
> Make sense
On Fri, Sep 18, 2020 at 06:37:19PM +0200, Christoph Hellwig wrote:
> There is no obvious reason why zsmalloc needs to pre-fault the PTEs
> given that it later uses map_kernel_range to just like vmap().
IIRC, the problem was runtime pte popluating needs GFP_KERNEL but
zs_map_object API runs under
use copies.
>
> Signed-off-by: Christoph Hellwig
> Acked-by: Peter Zijlstra (Intel)
Acked-by: Minchan Kim
Thanks!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Christoph,
Sorry for the late.
On Sat, Apr 11, 2020 at 09:20:52AM +0200, Christoph Hellwig wrote:
> Hi Minchan,
>
> On Fri, Apr 10, 2020 at 04:11:36PM -0700, Minchan Kim wrote:
> > It doesn't mean we couldn't use zsmalloc as module any longer. It means
> > we couldn't u
Hi Sergey,
On Fri, Apr 10, 2020 at 11:38:45AM +0900, Sergey Senozhatsky wrote:
> On (20/04/09 10:08), Minchan Kim wrote:
> > > > Even though I don't know how many usecase we have using zsmalloc as
> > > > module(I heard only once by dumb reason), it could affect e
On Thu, Apr 09, 2020 at 06:50:30PM +0200, Peter Zijlstra wrote:
> On Thu, Apr 09, 2020 at 09:08:26AM -0700, Minchan Kim wrote:
> > On Wed, Apr 08, 2020 at 01:59:08PM +0200, Christoph Hellwig wrote:
> > > This allows to unexport map_vm_area and unmap_kernel_range, which are
On Wed, Apr 08, 2020 at 01:59:08PM +0200, Christoph Hellwig wrote:
> This allows to unexport map_vm_area and unmap_kernel_range, which are
> rather deep internal and should not be available to modules.
Even though I don't know how many usecase we have using zsmalloc as
module(I heard only once by
On Wed, Apr 08, 2020 at 01:59:07PM +0200, Christoph Hellwig wrote:
> Rename the Kconfig variable to clarify the scope.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Minchan Kim
___
dri-devel mailing list
dri-devel@lists.freedesktop.
On Mon, Jul 04, 2016 at 10:55:09AM +0100, Mel Gorman wrote:
> On Mon, Jul 04, 2016 at 05:04:12PM +0900, Minchan Kim wrote:
> > > > How big ratio between highmem:lowmem do you think a problem?
> > > >
> > >
> > > That's a "how long is
On Mon, Jul 04, 2016 at 05:34:05AM +0100, Mel Gorman wrote:
> On Mon, Jul 04, 2016 at 10:37:03AM +0900, Minchan Kim wrote:
> > > The reason we have zone-based reclaim is that we used to have
> > > large highmem zones in common configurations and it was necessary
> > &g
On Thu, Jun 30, 2016 at 11:26:45AM +0530, Anshuman Khandual wrote:
> >> Did you get a chance to test the driver out ? I am still concerned about
> >> how to
> >> handle the struct address_space override problem within the struct page.
> >
> > Hi Anshuman,
> >
> > Slow but I am working on
On Mon, Jun 27, 2016 at 11:21:01AM +0530, Anshuman Khandual wrote:
> On 06/16/2016 11:07 AM, Minchan Kim wrote:
> > On Thu, Jun 16, 2016 at 09:12:07AM +0530, Anshuman Khandual wrote:
> >> On 06/16/2016 05:56 AM, Minchan Kim wrote:
> >>> On Wed, Jun 15, 2016 at 12:15
On Thu, Jun 16, 2016 at 05:42:11PM +0900, Sergey Senozhatsky wrote:
> On (06/16/16 15:47), Minchan Kim wrote:
> > > [..]
> > > > > this is what I'm getting with the [zsmalloc: keep first object offset
> > > > > in struct page]
> > > > > ap
On Thu, Jun 16, 2016 at 02:22:09PM +0900, Sergey Senozhatsky wrote:
> On (06/16/16 13:47), Minchan Kim wrote:
> [..]
> > > this is what I'm getting with the [zsmalloc: keep first object offset in
> > > struct page]
> > > applied: "count:0 mapcount:-127&
On Thu, Jun 16, 2016 at 09:12:07AM +0530, Anshuman Khandual wrote:
> On 06/16/2016 05:56 AM, Minchan Kim wrote:
> > On Wed, Jun 15, 2016 at 12:15:04PM +0530, Anshuman Khandual wrote:
> >> On 06/15/2016 08:02 AM, Minchan Kim wrote:
> >>> Hi,
> >>>
>
On Thu, Jun 16, 2016 at 01:23:43PM +0900, Sergey Senozhatsky wrote:
> On (06/16/16 11:58), Minchan Kim wrote:
> [..]
> > RAX: 2065676162726166 so rax is totally garbage, I think.
> > It means obj_to_head returns garbage because get_first_obj_offset is
> > utter crab b
On Thu, Jun 16, 2016 at 11:48:27AM +0900, Sergey Senozhatsky wrote:
> Hi,
>
> On (06/16/16 08:12), Minchan Kim wrote:
> > > [ 315.146533] kasan: CONFIG_KASAN_INLINE enabled
> > > [ 315.146538] kasan: GPF could be caused by NULL-ptr deref or user
> > > memory
On Wed, Jun 15, 2016 at 12:15:04PM +0530, Anshuman Khandual wrote:
> On 06/15/2016 08:02 AM, Minchan Kim wrote:
> > Hi,
> >
> > On Mon, Jun 13, 2016 at 03:08:19PM +0530, Anshuman Khandual wrote:
> >> > On 05/31/2016 05:31 AM, Minchan Kim wrote:
> &g
Hi Sergey,
On Wed, Jun 15, 2016 at 04:59:09PM +0900, Sergey Senozhatsky wrote:
> Hello Minchan,
>
> -next 4.7.0-rc3-next-20160614
>
>
> [ 315.146533] kasan: CONFIG_KASAN_INLINE enabled
> [ 315.146538] kasan: GPF could be caused by NULL-ptr deref or user memory
> access
> [ 315.146546]
Hi,
On Mon, Jun 13, 2016 at 03:08:19PM +0530, Anshuman Khandual wrote:
> On 05/31/2016 05:31 AM, Minchan Kim wrote:
> > @@ -791,6 +921,7 @@ static int __unmap_and_move(struct page *page, struct
> > page *newpage,
> > int rc = -EAGAIN;
> > int page_was_mapped =
On Wed, Jun 01, 2016 at 02:41:51PM -0700, Andrew Morton wrote:
> On Wed, 1 Jun 2016 08:21:09 +0900 Minchan Kim wrote:
>
> > Recently, I got many reports about perfermance degradation in embedded
> > system(Android mobile phone, webOS TV and so on) and easy fork fail.
&g
n Corbet
Cc: John Einar Reitan
Cc: dri-devel at lists.freedesktop.org
Cc: Sergey Senozhatsky
Acked-by: Vlastimil Babka
Signed-off-by: Gioh Kim
Signed-off-by: Minchan Kim
---
Documentation/filesystems/Locking | 4 +
Documentation/filesystems/vfs.txt | 11 +++
Documentation/vm/page_migration | 107 +++
onsoo Kim
Cc: Konstantin Khlebnikov
Cc: Mel Gorman
Cc: Naoya Horiguchi
Cc: Rafael Aquini
Cc: Rik van Riel
Cc: Sergey Senozhatsky
Cc: virtualization at lists.linux-foundation.org
Cc: Gioh Kim
Cc: Chan Gyun Jeong
Cc: Sangseok Lee
Cc: Kyeongdon Kim
Cc: Chulmin Kim
Minchan Kim (12):
mm:
On Tue, May 31, 2016 at 09:52:48AM +0200, Vlastimil Babka wrote:
> On 05/31/2016 02:01 AM, Minchan Kim wrote:
> >Per Vlastimi's review comment.
> >
> >Thanks for the detail review, Vlastimi!
> >If you have another concern, feel free to say.
>
> I don't for now :)
Per Vlastimi's review comment.
Thanks for the detail review, Vlastimi!
If you have another concern, feel free to say.
After I resolve all thing, I will send v7 rebased on recent mmotm.
>From b14aab2d3ac0702c7b2eec36409d74406d43 Mon Sep 17 00:00:00 2001
From: Minchan Kim <minc...@kern
On Mon, May 30, 2016 at 11:36:07AM +0200, Vlastimil Babka wrote:
> On 05/30/2016 03:39 AM, Minchan Kim wrote:
> >After isolation, VM calls migratepage of driver with isolated page.
> >The function of migratepage is to move content of the old page to new page
> >and set up
Per Vlastimil's review comment,
Vlastimil, I updated based on your comment. Please review this.
If everything is done, I will send v7 rebased on recent mmotm.
Thanks for the review!
>From ad4157e98651a2d18fd0a4ae90d1d9f609aab314 Mon Sep 17 00:00:00 2001
From: Minchan Kim <minc...@kern
On Fri, May 27, 2016 at 04:26:21PM +0200, Vlastimil Babka wrote:
> On 05/20/2016 04:23 PM, Minchan Kim wrote:
> >We have allowed migration for only LRU pages until now and it was
> >enough to make high-order pages. But recently, embedded system(e.g.,
> >webOS, android) use
n Corbet
Cc: John Einar Reitan
Cc: dri-devel at lists.freedesktop.org
Cc: Sergey Senozhatsky
Signed-off-by: Gioh Kim
Signed-off-by: Minchan Kim
---
Documentation/filesystems/Locking | 4 +
Documentation/filesystems/vfs.txt | 11 +++
Documentation/vm/page_migration | 107 -
include/linux/comp
nozhatsky
Cc: virtualization at lists.linux-foundation.org
Cc: Gioh Kim
Cc: Chan Gyun Jeong
Cc: Sangseok Lee
Cc: Kyeongdon Kim
Cc: Chulmin Kim
Minchan Kim (12):
mm: use put_page to free page instead of putback_lru_page
mm: migrate: support non-lru movable page migration
mm: balloon: use ge
On Mon, May 16, 2016 at 04:17:51PM +0900, Sergey Senozhatsky wrote:
> On (05/09/16 11:20), Minchan Kim wrote:
> [..]
> > +++ b/include/linux/migrate.h
> > @@ -32,11 +32,16 @@ extern char *migrate_reason_names[MR_TYPES];
> >
> > #ifdef CONFIG_MIGRATION
> >
On Mon, May 16, 2016 at 04:04:55PM +0900, Sergey Senozhatsky wrote:
> On (05/09/16 11:20), Minchan Kim wrote:
> > +++ b/include/linux/migrate.h
> > @@ -32,11 +32,16 @@ extern char *migrate_reason_names[MR_TYPES];
> >
> > #ifdef CONFIG_MIGRATION
> >
> &
n Corbet
Cc: John Einar Reitan
Cc: dri-devel at lists.freedesktop.org
Cc: Sergey Senozhatsky
Signed-off-by: Gioh Kim
Signed-off-by: Minchan Kim
---
Documentation/filesystems/Locking | 4 +
Documentation/filesystems/vfs.txt | 11 ++
Documentation/vm/page_migration | 107 +-
incl
c: Konstantin Khlebnikov
Cc: Mel Gorman
Cc: Naoya Horiguchi
Cc: Rafael Aquini
Cc: Rik van Riel
Cc: Sergey Senozhatsky
Cc: virtualization at lists.linux-foundation.org
Cc: Gioh Kim
Cc: Chan Gyun Jeong
Cc: Sangseok Lee
Cc: Kyeongdon Kim
Cc: Chulmin Kim
Minchan Kim (12):
mm: use put_page to free
Hello Andrew,
On Wed, Apr 27, 2016 at 01:20:35PM -0700, Andrew Morton wrote:
> On Wed, 27 Apr 2016 16:48:13 +0900 Minchan Kim wrote:
>
> > Recently, I got many reports about perfermance degradation in embedded
> > system(Android mobile phone, webOS TV and so on)
n Corbet
Cc: John Einar Reitan
Cc: dri-devel at lists.freedesktop.org
Cc: Sergey Senozhatsky
Signed-off-by: Gioh Kim
Signed-off-by: Minchan Kim
---
Documentation/filesystems/Locking | 4 +
Documentation/filesystems/vfs.txt | 11 ++
Documentation/vm/page_migration | 107 +-
incl
: Chulmin Kim
Minchan Kim (12):
mm: use put_page to free page instead of putback_lru_page
mm: migrate: support non-lru movable page migration
mm: balloon: use general non-lru movable page feature
zsmalloc: keep max_object in size_class
zsmalloc: use bit_spin_lock
zsmalloc: use accessor
zsm
On Mon, Apr 04, 2016 at 03:24:34PM +0200, Vlastimil Babka wrote:
> On 04/04/2016 07:12 AM, Minchan Kim wrote:
> >On Fri, Apr 01, 2016 at 11:29:14PM +0200, Vlastimil Babka wrote:
> >>Might have been better as a separate migration patch and then a
> >>compaction patch.
good idea
to separate compaction and migration part.
I will just resend to change the tile from "mm/compaction" to
"mm/migration".
>
> On 03/30/2016 09:12 AM, Minchan Kim wrote:
> >We have allowed migration for only LRU pages until now and it was
> >enough to make high
-devel at lists.freedesktop.org
Cc: virtualization at lists.linux-foundation.org
Signed-off-by: Gioh Kim
Signed-off-by: Minchan Kim
---
Documentation/filesystems/Locking | 4 +
Documentation/filesystems/vfs.txt | 5 +
fs/proc/page.c | 3 +
include/linu
On Thu, Mar 24, 2016 at 05:26:50AM +0900, Gioh Kim wrote:
>Hmmm... But, in failure case, is it safe to call putback_lru_page() for
>them?
>And, PageIsolated() would be left. Is it okay? It's not symmetric that
>isolated page can be freed by decreasing ref count without calling
>
On Wed, Mar 23, 2016 at 02:05:11PM +0900, Joonsoo Kim wrote:
> On Tue, Mar 22, 2016 at 11:55:45PM +0900, Minchan Kim wrote:
> > On Tue, Mar 22, 2016 at 02:50:37PM +0900, Joonsoo Kim wrote:
> > > On Mon, Mar 21, 2016 at 03:31:02PM +0900, Minchan Kim wrote:
> > > > We h
On Tue, Mar 22, 2016 at 02:50:37PM +0900, Joonsoo Kim wrote:
> On Mon, Mar 21, 2016 at 03:31:02PM +0900, Minchan Kim wrote:
> > We have allowed migration for only LRU pages until now and it was
> > enough to make high-order pages. But recently, embedded system(e.g.,
> > webO
ee.
4. If migration fails, putback function of subsystem should
clear PG_isolated via ClearPageIsolated.
Cc: Vlastimil Babka
Cc: Mel Gorman
Cc: Hugh Dickins
Cc: dri-devel at lists.freedesktop.org
Cc: virtualization at lists.linux-foundation.org
Signed-off-by: Gioh Kim
Signed-off-by: Minch
;
> url:
> https://github.com/0day-ci/linux/commits/Minchan-Kim/Support-non-lru-page-migration/20160311-153649
> config: x86_64-nfsroot (attached as .config)
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64
>
> All erro
ee.
4. If migration fails, putback function of subsystem should
clear PG_isolated via ClearPageIsolated.
Cc: Vlastimil Babka
Cc: Mel Gorman
Cc: Hugh Dickins
Cc: dri-devel at lists.freedesktop.org
Cc: virtualization at lists.linux-foundation.org
Signed-off-by: Gioh Kim
Signed-off-by: Minch
On Fri, Jul 31, 2015 at 07:43:09PM +0900, Minchan Kim wrote:
> Hi Gioh,
>
> On Mon, Jul 13, 2015 at 05:35:17PM +0900, Gioh Kim wrote:
> > From: Gioh Kim
> >
> > Add framework to register callback functions and check page mobility.
> > There are some modes f
Hi Gioh,
On Mon, Jul 13, 2015 at 05:35:17PM +0900, Gioh Kim wrote:
> From: Gioh Kim
>
> Add framework to register callback functions and check page mobility.
> There are some modes for page isolation so that isolate interface
> has arguments of page address and isolation mode while putback
>
aid, we wil add big comments
> describing this feature enough to next patch.
>
> Thanks,
> Inki Dae
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo at kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
> Don't email: mailto:"dont at kvack.org"> email at kvack.org
>
--
Kind regards,
Minchan Kim
...@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a
--
Kind regards,
Minchan Kim
similar access, here obviously the page backing the
>> scratch area can be stole at each glteximage call.
>>
>> Anyway if you can define your api and provision that after call the
>> data you provided is no longer available then use case 1 sounds doable
>> and worth it to me.
>>
>
> How about forcing VM_DONTCOPY not to copy the vma on fork? this flag may
> prevent doing COW. and I was talked that get_user_pages call avoid the pages
That was why we introduced MADV_DONTFORK.
> from being swapped out, not using mlock. if all the pages from
True.
> get_user_pages are MOVABLE then CMA would try to migrate movable pages into
> reserved space for DMA once device driver tries allocation through dma api
> so if we could prevent the pages from being moved by CMA and we limit
CMA can't migrate pinning pages which have increased page count by
get_user_pages.
So don't worry about it.
> maximum size for userptr(accessed by only root user) then I guess that we
> could avoid these issues. there may be many things I don't care so please
> give me any comments and advices.
>
> Thanks,
> Inki Dae
>
>
>>> So he needs to keep around these mappings for essentially forever to
>>> amortize the setup cost, which boils down to your 2nd use-case. I've
>>> refused to merge that code since, like you point out, too much stuff can
>>> go wrong when we pin arbitrary ranges of userspace.
>>>
>>> One example which would only affect ARM platforms is that this would
>>> horribly break CMA: Userspace malloc is allocated as GFP_MOVEABLE, and
>> CMA
>>> relies on migrating moveable pages out of the CMA region to handle large
>>> contigious allocations. Currently the page migrate code simply backs
>> down
>>> and waits a bit if it encounters a page locked by get_user_pages,
>> assuming
>>> that this is due to io and will complete shortly. If you hold onto such
>>> pages for a long time, that retry will eventually fail and break CMA.
>>>
>>> There are other problems affecting also desktop machines, but I've
>> figured
>>> I'll pick something that really hurts on arm ;-)
>>>
>>> Yours, Daniel
>>> --
>>> Daniel Vetter
>>> Mail: daniel at ffwll.ch
>>> Mobile: +41 (0)79 365 57 48
>>
>> Yes, what i also wanted to stress is that get_user_pages is not
>> enough, we are not doing something over the period of an ioctl in
>> which case everything is fine and doable, but are stealing page and
>> expect to use them at random point in the future with no kind of
>> synchronization with userspace. Anyway i think we agree that this
>> second use case is way complex and many things can go wrong, i still
>> think that for opencl we might want to able to do it but by them i am
>> expecting we will take advantage of iommu being able to pagefault from
>> process pagetable like the next AMD iommu can.
>>
>> Cheers,
>> Jerome
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo at kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
> Don't email: email at kvack.org
>
--
Kind regards,
Minchan Kim
/8/29/295
so I think mlock is a kind of page pinning. If elsewhere I don't realized is
doing, that place should be fixed.
Or my above patch should go ahead.
>
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo at kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Fight unfair telecom internet charges in Canada: sign
> http://stopthemeter.ca/
> Don't email: mailto:"dont at kvack.org"> email at kvack.org
>
--
Kind regards,
Minchan Kim
: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign
http://stopthemeter.ca/
Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a
--
Kind regards,
Minchan Kim
___
dri-devel mailing list
dri-devel
unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: a href=ilto:d...@kvack.org em...@kvack.org /a
--
Kind regards,
Minchan Kim
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org
On 05/10/2012 04:59 PM, InKi Dae wrote:
> 2012/5/10, Minchan Kim :
>> On 05/10/2012 03:57 PM, Inki Dae wrote:
>>
>>>
>>>
>>>> -----Original Message-
>>>> From: Minchan Kim [mailto:minchan at kernel.org]
>>>> Sent: Thu
On 05/10/2012 04:56 PM, Minchan Kim wrote:
> On 05/10/2012 04:31 PM, Kyungmin Park wrote:
>
>> On 5/10/12, Minchan Kim wrote:
>>> On 05/10/2012 03:53 PM, KOSAKI Motohiro wrote:
>>>
>>>> (5/10/12 12:58 AM), Minchan Kim wrote:
>>>>> On 05
On 05/10/2012 04:31 PM, Kyungmin Park wrote:
> On 5/10/12, Minchan Kim wrote:
>> On 05/10/2012 03:53 PM, KOSAKI Motohiro wrote:
>>
>>> (5/10/12 12:58 AM), Minchan Kim wrote:
>>>> On 05/10/2012 10:39 AM, Inki Dae wrote:
>>>>
>>>>>
On 05/10/2012 03:53 PM, KOSAKI Motohiro wrote:
> (5/10/12 12:58 AM), Minchan Kim wrote:
>> On 05/10/2012 10:39 AM, Inki Dae wrote:
>>
>>> Hi Jerome,
>>>
>>>> -Original Message-
>>>> From: Jerome Glisse [mailto:j.glisse
On 05/10/2012 03:57 PM, Inki Dae wrote:
>
>
>> -Original Message-----
>> From: Minchan Kim [mailto:minchan at kernel.org]
>> Sent: Thursday, May 10, 2012 1:58 PM
>> To: Inki Dae
>> Cc: 'Jerome Glisse'; airlied at linux.ie; dri-devel at lists.freedesktop.
w
>> anonymous memory).
I don't know history in detail because you didn't have sent full patches to
linux-mm and
I didn't read the below code, either.
Just read your description and reply of Jerome. Apparently, there is something
I missed.
Your goal is to avoid swap out some user pages which is used in kernel at the
same time. Right?
Let's use get_user_pages. Is there any issue you can't use it?
It increases page count so reclaimer can't swap out page.
Isn't it enough?
Marking whole VMA into MLCOKED is overkill.
--
Kind regards,
Minchan Kim
On 05/10/2012 04:56 PM, Minchan Kim wrote:
On 05/10/2012 04:31 PM, Kyungmin Park wrote:
On 5/10/12, Minchan Kim minc...@kernel.org wrote:
On 05/10/2012 03:53 PM, KOSAKI Motohiro wrote:
(5/10/12 12:58 AM), Minchan Kim wrote:
On 05/10/2012 10:39 AM, Inki Dae wrote:
Hi Jerome
On 05/10/2012 03:57 PM, Inki Dae wrote:
-Original Message-
From: Minchan Kim [mailto:minc...@kernel.org]
Sent: Thursday, May 10, 2012 1:58 PM
To: Inki Dae
Cc: 'Jerome Glisse'; airl...@linux.ie; dri-devel@lists.freedesktop.org;
kyungmin.p...@samsung.com; sw0312@samsung.com
On 05/10/2012 03:53 PM, KOSAKI Motohiro wrote:
(5/10/12 12:58 AM), Minchan Kim wrote:
On 05/10/2012 10:39 AM, Inki Dae wrote:
Hi Jerome,
-Original Message-
From: Jerome Glisse [mailto:j.gli...@gmail.com]
Sent: Wednesday, May 09, 2012 11:46 PM
To: Inki Dae
Cc: airl...@linux.ie
On 05/10/2012 04:31 PM, Kyungmin Park wrote:
On 5/10/12, Minchan Kim minc...@kernel.org wrote:
On 05/10/2012 03:53 PM, KOSAKI Motohiro wrote:
(5/10/12 12:58 AM), Minchan Kim wrote:
On 05/10/2012 10:39 AM, Inki Dae wrote:
Hi Jerome,
-Original Message-
From: Jerome Glisse
On 05/10/2012 04:59 PM, InKi Dae wrote:
2012/5/10, Minchan Kim minc...@kernel.org:
On 05/10/2012 03:57 PM, Inki Dae wrote:
-Original Message-
From: Minchan Kim [mailto:minc...@kernel.org]
Sent: Thursday, May 10, 2012 1:58 PM
To: Inki Dae
Cc: 'Jerome Glisse'; airl...@linux.ie
issue you can't use it?
It increases page count so reclaimer can't swap out page.
Isn't it enough?
Marking whole VMA into MLCOKED is overkill.
--
Kind regards,
Minchan Kim
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
71 matches
Mail list logo
