(10/7/13 5:18 PM), Jan Kara wrote:
On Fri 04-10-13 16:42:19, KOSAKI Motohiro wrote:
(10/4/13 4:31 PM), KOSAKI Motohiro wrote:
(10/2/13 4:29 PM), Jan Kara wrote:
On Wed 02-10-13 09:20:09, Christoph Hellwig wrote:
On Wed, Oct 02, 2013 at 04:27:41PM +0200, Jan Kara wrote:
Hello,
In my
(5/14/12 2:52 AM), Inki Dae wrote:
-Original Message-
From: KOSAKI Motohiro [mailto:kosaki.motoh...@gmail.com]
Sent: Monday, May 14, 2012 3:33 PM
To: Inki Dae
Cc: airl...@linux.ie; dri-devel@lists.freedesktop.org; j.gli...@gmail.com;
minc...@kernel.org; kyungmin.p...@samsung.com
(5/14/12 2:52 AM), Inki Dae wrote:
>
>
>> -Original Message-----
>> From: KOSAKI Motohiro [mailto:kosaki.motohiro at gmail.com]
>> Sent: Monday, May 14, 2012 3:33 PM
>> To: Inki Dae
>> Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org; j
> + ? ? ? npages = buf->size >> PAGE_SHIFT;
Why round down? usually we use round up.
> + ? ? ? down_read(>mm->mmap_sem);
> +
> + ? ? ? /*
> + ? ? ? ?* Basically, all the pages from get_user_pages() can not be not only
> + ? ? ? ?* migrated by CMA but also swapped out.
> + ? ? ? ?*
> + ? ? ? ?*
+ npages = buf-size PAGE_SHIFT;
Why round down? usually we use round up.
+ down_read(current-mm-mmap_sem);
+
+ /*
+ * Basically, all the pages from get_user_pages() can not be not only
+ * migrated by CMA but also swapped out.
+ *
+ * The
(5/10/12 11:01 PM), Jerome Glisse wrote:
On Thu, May 10, 2012 at 10:51 PM, KOSAKI Motohiro
kosaki.motoh...@gmail.com wrote:
(5/10/12 8:50 PM), Minchan Kim wrote:
Hi KOSAKI,
On 05/11/2012 02:53 AM, KOSAKI Motohiro wrote:
let's assume that one application want to allocate user space memory
My point is this ioctl will be restricted to one user (Xserver if i
understand) and only this user, there is no fork in it so no need to
worry about fork, just setting the vma as locked will be enough.
But i don't want people reading this driver suddenly think that what
it's doing is ok, it's
On Fri, May 11, 2012 at 7:29 PM, Jerome Glisse j.gli...@gmail.com wrote:
On Fri, May 11, 2012 at 6:59 PM, KOSAKI Motohiro
kosaki.motoh...@gmail.com wrote:
My point is this ioctl will be restricted to one user (Xserver if i
understand) and only this user, there is no fork in it so no need
On Fri, May 11, 2012 at 7:29 PM, Jerome Glisse wrote:
> On Fri, May 11, 2012 at 6:59 PM, KOSAKI Motohiro
> wrote:
>>> My point is this ioctl will be restricted to one user (Xserver if i
>>> understand) and only this user, there is no fork in it so no need to
>>&g
> My point is this ioctl will be restricted to one user (Xserver if i
> understand) and only this user, there is no fork in it so no need to
> worry about fork, just setting the vma as locked will be enough.
>
> But i don't want people reading this driver suddenly think that what
> it's doing is
let's assume that one application want to allocate user space memory
region using malloc() and then write something on the region. as you
may know, user space buffer doen't have real physical pages once
malloc() call so if user tries to access the region then page fault
handler would be triggered
(5/10/12 8:50 PM), Minchan Kim wrote:
> Hi KOSAKI,
>
> On 05/11/2012 02:53 AM, KOSAKI Motohiro wrote:
>
>>>>> let's assume that one application want to allocate user space memory
>>>>> region using malloc() and then write something on the region. as yo
>>> let's assume that one application want to allocate user space memory
>>> region using malloc() and then write something on the region. as you
>>> may know, user space buffer doen't have real physical pages once
>>> malloc() call so if user tries to access the region then page fault
>>> handler
(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 at gmail.com]
>>> Sent: Wednesday, May 09, 2012 11:46 PM
>>> To: Inki Dae
>>> Cc: airlied at linux.ie; dri-devel at
(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; dri-devel@lists.freedesktop.org;
>> If you are thinking the shrinker protocol is too complicated, doc update
>> patch is really welcome.
>
> Slab shrinkers have a nasty, crappy interface and the shrink_slab()
> code is full of bugs. Rather that telling people to "update the
> documentation" because it's too complex, how about
If you are thinking the shrinker protocol is too complicated, doc update
patch is really welcome.
Slab shrinkers have a nasty, crappy interface and the shrink_slab()
code is full of bugs. Rather that telling people to update the
documentation because it's too complex, how about we fix the
(2011/07/13 16:41), Chris Wilson wrote:
> On Wed, 13 Jul 2011 09:19:24 +0900, KOSAKI Motohiro jp.fujitsu.com> wrote:
>> (2011/07/12 19:06), Chris Wilson wrote:
>>> On Tue, 12 Jul 2011 18:36:50 +0900, KOSAKI Motohiro >> jp.fujitsu.com> wrote:
>>
(2011/07/12 19:06), Chris Wilson wrote:
> On Tue, 12 Jul 2011 18:36:50 +0900, KOSAKI Motohiro jp.fujitsu.com> wrote:
>> Hi,
>>
>> sorry for the delay.
>>
>>> On Wed, 29 Jun 2011 20:53:54 -0700, Keith Packard
>>> wrote:
>>>> On Fri, 24
(2011/07/12 19:06), Chris Wilson wrote:
On Tue, 12 Jul 2011 18:36:50 +0900, KOSAKI Motohiro
kosaki.motoh...@jp.fujitsu.com wrote:
Hi,
sorry for the delay.
On Wed, 29 Jun 2011 20:53:54 -0700, Keith Packard kei...@keithp.com wrote:
On Fri, 24 Jun 2011 17:03:22 +0900, KOSAKI Motohiro
(2011/07/13 16:41), Chris Wilson wrote:
On Wed, 13 Jul 2011 09:19:24 +0900, KOSAKI Motohiro
kosaki.motoh...@jp.fujitsu.com wrote:
(2011/07/12 19:06), Chris Wilson wrote:
On Tue, 12 Jul 2011 18:36:50 +0900, KOSAKI Motohiro
kosaki.motoh...@jp.fujitsu.com wrote:
Hi,
sorry for the delay
Hi,
sorry for the delay.
> On Wed, 29 Jun 2011 20:53:54 -0700, Keith Packard
> wrote:
>> On Fri, 24 Jun 2011 17:03:22 +0900, KOSAKI Motohiro > jp.fujitsu.com> wrote:
>>
>>> Now, i915_gem_inactive_shrink() should return -1 instead of 0 if it
>>> can't
Hi,
sorry for the delay.
On Wed, 29 Jun 2011 20:53:54 -0700, Keith Packard kei...@keithp.com wrote:
On Fri, 24 Jun 2011 17:03:22 +0900, KOSAKI Motohiro
kosaki.motoh...@jp.fujitsu.com wrote:
Now, i915_gem_inactive_shrink() should return -1 instead of 0 if it
can't take a lock. Otherwise
Now, i915_gem_inactive_shrink() should return -1 instead of 0 if it
can't take a lock. Otherwise, vmscan is getting a lot of confusing
because vmscan can't distinguish "can't take a lock temporary" and
"we've shrank all of i915 objects".
Signed-off-by: KOSAKI Motohiro
C
Now, i915_gem_inactive_shrink() should return -1 instead of 0 if it
can't take a lock. Otherwise, vmscan is getting a lot of confusing
because vmscan can't distinguish can't take a lock temporary and
we've shrank all of i915 objects.
Signed-off-by: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
25 matches
Mail list logo
