Re: Linux 2.6.37

2011-01-06 Thread Michal Hocko
[...] -- Michal Hocko L3 team SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 2.6.37

2011-01-06 Thread Michal Hocko
Just for reference, my initial report was: https://lkml.org/lkml/2010/11/23/146 On Thu 06-01-11 08:29:22, Linus Torvalds wrote: On Thu, Jan 6, 2011 at 2:48 AM, Michal Hocko mho...@suse.cz wrote: It seems that there is still a regression for intel graphic cards backlight. One report

Re: Linux 2.6.37

2011-01-07 Thread Michal Hocko
. Whatever. It does not help. The backlight stays off. It didn't help in my case either -- Michal Hocko L3 team SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic ___ dri-devel mailing list dri-devel@lists.freedesktop.org http

Re: Linux 2.6.37

2011-01-11 Thread Michal Hocko
driver: [...] (II) Loading extension DRI2 (II) LoadModule: intel (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so [...] So this doesn't look like the case. -- Michal Hocko L3 team SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic

Re: Linux 2.6.37

2011-01-11 Thread Michal Hocko
[Let's CC Indan - author of the bugzilla patches] On Thu 06-01-11 11:48:16, Michal Hocko wrote: Hi, On Tue 04-01-11 17:15:45, Linus Torvalds wrote: [...] We did have another revert to fix hopefullythe last blank screen regression on intel graphics. It seems that there is still

Re: Linux 2.6.37

2011-01-11 Thread Michal Hocko
On Tue 11-01-11 18:17:44, Michal Hocko wrote: [Let's CC Indan - author of the bugzilla patches] On Thu 06-01-11 11:48:16, Michal Hocko wrote: Hi, On Tue 04-01-11 17:15:45, Linus Torvalds wrote: [...] We did have another revert to fix hopefullythe last blank screen regression

Re: Linux 2.6.37

2011-01-11 Thread Michal Hocko
On Tue 11-01-11 17:39:42, Chris Wilson wrote: On Tue, 11 Jan 2011 18:19:17 +0100, Michal Hocko mho...@suse.cz wrote: [Let's CC Indan - author of the bugzilla patches] On Thu 06-01-11 11:48:16, Michal Hocko wrote: Hi, On Tue 04-01-11 17:15:45, Linus Torvalds wrote: [...] We

Re: Linux 2.6.37

2011-01-11 Thread Michal Hocko
On Tue 11-01-11 18:37:41, Michal Hocko wrote: On Tue 11-01-11 18:17:44, Michal Hocko wrote: [Let's CC Indan - author of the bugzilla patches] On Thu 06-01-11 11:48:16, Michal Hocko wrote: Hi, On Tue 04-01-11 17:15:45, Linus Torvalds wrote: [...] We did have another revert

[PATCH] hugetlb: release pages in the error path of hugetlb_cow() (was: Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1)

2011-11-28 Thread Michal Hocko
-page_table_lock); return VM_FAULT_OOM; -- 1.7.7.3 -- Michal Hocko SUSE Labs SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org

[PATCH] drm: fix i_mapping and f_mapping initialization in drm_open in error path

2013-03-26 Thread Michal Hocko
+). Thanks! --- From a786a701bd6c277329e2b788fea9a69b1c3ced2e Mon Sep 17 00:00:00 2001 From: Michal Hocko mho...@suse.cz Date: Tue, 26 Mar 2013 19:04:40 +0100 Subject: [PATCH] drm: fix i_mapping and f_mapping initialization in drm_open in error path Starting with fdb40a08 (drm: set dev_mapping before

Re: [PATCH] drm: fix i_mapping and f_mapping initialization in drm_open in error path

2013-03-31 Thread Michal Hocko
= old_mapping; + filp-f_mapping = old_fmapping; + inode-i_mapping = old_imapping; iput(container_of(dev-dev_mapping, struct inode, i_data)); dev-dev_mapping = old_mapping; mutex_unlock(dev-struct_mutex); -- 1.8.1.5 -- Michal Hocko SUSE Labs

Re: [PATCH] drm: fix i_mapping and f_mapping initialization in drm_open in error path

2013-04-02 Thread Michal Hocko
On Mon 01-04-13 13:14:50, Ilija Hadzic wrote: On Sun, 31 Mar 2013, Michal Hocko wrote: On Sat 30-03-13 18:26:53, Ilija Hadzic wrote: This looks a bit like a hack and it doesn't look right, conceptually. If the call fails, it should restore things as if nothing has ever happened

Re: [PATCH 3/8] mm: cma: Export a few symbols

2017-02-20 Thread Michal Hocko
On Mon 13-02-17 14:44:16, Maxime Ripard wrote: > Hi Michal, > > On Thu, Feb 09, 2017 at 08:20:47PM +0100, Michal Hocko wrote: > > [CC CMA people] > > > > On Thu 09-02-17 17:39:17, Maxime Ripard wrote: > > > Modules might want to check their CMA

Re: [PATCH 3/8] mm: cma: Export a few symbols

2017-02-09 Thread Michal Hocko
es 0.8.11 > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org;> em...@kvack.org -- Michal Hocko SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] mm: add locked parameter to get_user_pages_remote()

2016-10-27 Thread Michal Hocko
flexibility in the > use of get_user_pages_remote(). I would also add that this shouldn't introduce any functional change. > Signed-off-by: Lorenzo Stoakes Acked-by: Michal Hocko > --- > drivers/gpu/drm/etnaviv/etnaviv_gem.c | 2 +- > drivers/gpu/drm/i915/i915_gem_userp

[PATCH 2/2] mm: unexport __get_user_pages_unlocked()

2016-10-27 Thread Michal Hocko
cing it is therefore not an issue. Looks good to me. > Signed-off-by: Lorenzo Stoakes Acked-by: Michal Hocko > --- > include/linux/mm.h | 3 --- > mm/gup.c | 8 > mm/nommu.c | 7 +++ > mm/process_vm_access.c | 12 &g

[PATCH 1/2] mm: add locked parameter to get_user_pages_remote()

2016-10-27 Thread Michal Hocko
On Thu 27-10-16 12:55:27, Michal Hocko wrote: > On Thu 27-10-16 10:51:40, Lorenzo Stoakes wrote: > > This patch adds a int *locked parameter to get_user_pages_remote() to allow > > VM_FAULT_RETRY faulting behaviour similar to get_user_pages_[un]locked(). > > > > Takin

[PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags

2016-10-18 Thread Michal Hocko
_FORCE users was always a nightmare and the flag behavior is really subtle so we should better be explicit about it. I haven't gone through each patch separately but rather applied the whole series and checked the resulting diff. This all seems OK to me and feel free to add Acked-by: Michal Hocko I am w

[PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags

2016-10-19 Thread Michal Hocko
On Wed 19-10-16 09:58:15, Lorenzo Stoakes wrote: > On Tue, Oct 18, 2016 at 05:30:50PM +0200, Michal Hocko wrote: > > I am wondering whether we can go further. E.g. it is not really clear to > > me whether we need an explicit FOLL_REMOTE when we can in fact check > > mm !=

[PATCH 08/10] mm: replace __access_remote_vm() write parameter with gup_flags

2016-10-19 Thread Michal Hocko
On Wed 19-10-16 09:40:45, Lorenzo Stoakes wrote: > On Wed, Oct 19, 2016 at 10:13:52AM +0200, Michal Hocko wrote: > > On Wed 19-10-16 09:59:03, Jan Kara wrote: > > > On Thu 13-10-16 01:20:18, Lorenzo Stoakes wrote: > > > > This patch removes the write par

[PATCH 08/10] mm: replace __access_remote_vm() write parameter with gup_flags

2016-10-19 Thread Michal Hocko
FORCE for access_remote_vm? I mean FOLL_FORCE is a really non-trivial thing. It doesn't obey vma permissions so we should really minimize its usage. Do all of those users really need FOLL_FORCE? Anyway I would rather see the flag explicit and used at more places than hidden behind a helper function. -- Michal Hocko SUSE Labs

[PATCH 08/10] mm: replace __access_remote_vm() write parameter with gup_flags

2016-10-19 Thread Michal Hocko
On Wed 19-10-16 10:06:46, Lorenzo Stoakes wrote: > On Wed, Oct 19, 2016 at 10:52:05AM +0200, Michal Hocko wrote: > > yes this is the desirable and expected behavior. > > > > > wonder if this is desirable behaviour or whether this ought to be limited > > > to >

[PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags

2016-10-19 Thread Michal Hocko
On Wed 19-10-16 09:49:43, Dave Hansen wrote: > On 10/19/2016 02:07 AM, Michal Hocko wrote: > > On Wed 19-10-16 09:58:15, Lorenzo Stoakes wrote: > >> On Tue, Oct 18, 2016 at 05:30:50PM +0200, Michal Hocko wrote: > >>> I am wondering whether we can go further. E.g. it i

[PATCH] drm/amdgpu: use ERR_PTR() to return from amdgpu_mn_get

2016-04-28 Thread Michal Hocko
> from integer without a cast > > This adds the necessary ERR_PTR() conversion. > > Signed-off-by: Arnd Bergmann > Fixes: ad35eee9fb17 ("drm/amdgpu: make amdgpu_mn_get wait for mmap_sem > killable") This is in the mmotm tree so the sha is unstable. Acked-by: Michal Ho

drm/radeon spamming alloc_contig_range: [xxx, yyy) PFNs busy busy

2016-12-01 Thread Michal Hocko
Forgot to CC Joonsoo. The email thread starts more or less here http://lkml.kernel.org/r/20161130092239.GD18437 at dhcp22.suse.cz On Thu 01-12-16 08:15:07, Michal Hocko wrote: > On Wed 30-11-16 20:19:03, Robin H. Johnson wrote: > [...] > > alloc_contig_range: [83f2a3, 83f2a4) PFNs b

drm/radeon spamming alloc_contig_range: [xxx, yyy) PFNs busy busy

2016-12-01 Thread Michal Hocko
On Wed 30-11-16 20:19:03, Robin H. Johnson wrote: [...] > alloc_contig_range: [83f2a3, 83f2a4) PFNs busy Huh, do I get it right that the request was for a _single_ page? Why do we need CMA for that? -- Michal Hocko SUSE Labs

drm/radeon spamming alloc_contig_range: [xxx, yyy) PFNs busy busy

2016-12-01 Thread Michal Hocko
Let's also CC Marek On Thu 01-12-16 08:43:40, Vlastimil Babka wrote: > On 12/01/2016 08:21 AM, Michal Hocko wrote: > > Forgot to CC Joonsoo. The email thread starts more or less here > > http://lkml.kernel.org/r/20161130092239.GD18437 at dhcp22.suse.cz > > > > On Th

drm/radeon spamming alloc_contig_range: [xxx, yyy) PFNs busy busy

2016-12-01 Thread Michal Hocko
On Thu 01-12-16 17:03:52, Michal Nazarewicz wrote: > On Thu, Dec 01 2016, Michal Hocko wrote: > > Let's also CC Marek > > > > On Thu 01-12-16 08:43:40, Vlastimil Babka wrote: > >> On 12/01/2016 08:21 AM, Michal Hocko wrote: > >> > Forgot to CC Joonsoo.

[PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT

2015-08-12 Thread Michal Hocko
ld in the mm_struct. This could be handled at __mm_populate level. So unless I am missing something this would be much more easier in the end we no new bit in VM flags would be necessary. This would obviously mean that the LOCKONFAULT couldn't be exported to the userspace but is this really necessary? -- Michal Hocko SUSE Labs

[PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT

2015-08-20 Thread Michal Hocko
rong justification. If the discoverability is really needed then fair enough but I haven't seen any justification for that yet. -- Michal Hocko SUSE Labs

[PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT

2015-08-21 Thread Michal Hocko
On Thu 20-08-15 13:03:09, Eric B Munson wrote: > On Thu, 20 Aug 2015, Michal Hocko wrote: > > > On Wed 19-08-15 17:33:45, Eric B Munson wrote: > > [...] > > > The group which asked for this feature here > > > wants the ability to distinguish be

[PATCH] drm: fix i_mapping and f_mapping initialization in drm_open in error path

2013-03-26 Thread Michal Hocko
Hi, the patch bellow fixes a nullptr dereference reported with OpenSUSE12.3. I am not familiar with the area so I have no idea whether this is the right way to go but after applying this patch the problem is not reproducible anymore. If the patch is correct then please mark it for stable (3.7+).

[PATCH] drm: fix i_mapping and f_mapping initialization in drm_open in error path

2013-03-26 Thread Michal Hocko
00068 This patch fixes that by initializating old_mapping to the inode->i_data same as dev_mapping. Reported-and-tested-by: Marco Munderloh Signed-off-by: Michal Hocko --- drivers/gpu/drm/drm_fops.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_fops.c b/dr

[PATCH] drm: fix i_mapping and f_mapping initialization in drm_open in error path

2013-03-31 Thread Michal Hocko
> err_undo: > mutex_lock(>struct_mutex); > - filp->f_mapping = old_mapping; > - inode->i_mapping = old_mapping; > + filp->f_mapping = old_fmapping; > + inode->i_mapping = old_imapping; > iput(container_of(dev->dev_mapping, struct inode, i_data)); > dev->dev_mapping = old_mapping; > mutex_unlock(>struct_mutex); -- 1.8.1.5 -- Michal Hocko SUSE Labs

[PATCH] drm: fix i_mapping and f_mapping initialization in drm_open in error path

2013-04-02 Thread Michal Hocko
On Mon 01-04-13 13:14:50, Ilija Hadzic wrote: > > > On Sun, 31 Mar 2013, Michal Hocko wrote: > > >On Sat 30-03-13 18:26:53, Ilija Hadzic wrote: > >>This looks a bit like a hack and it doesn't look right, > >>conceptually. If the call fails, it should resto

[PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT

2015-08-25 Thread Michal Hocko
On Tue 25-08-15 15:55:46, Vlastimil Babka wrote: > On 08/25/2015 03:41 PM, Michal Hocko wrote: [...] > >So what we have as a result is that partially populated ranges are > >preserved and fully populated ones work in the best effort mode the same > >way as they are now. &

[PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT

2015-08-25 Thread Michal Hocko
On Tue 25-08-15 10:29:02, Eric B Munson wrote: > On Tue, 25 Aug 2015, Michal Hocko wrote: [...] > > Considering the current behavior I do not thing it would be terrible > > thing to do what Konstantin was suggesting and populate only the full > > ranges in a best effort mode

[PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT

2015-08-26 Thread Michal Hocko
call paths where gup is called unconditionally, I haven't checked that. -- Michal Hocko SUSE Labs

[PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT

2015-08-25 Thread Michal Hocko
eserved and fully populated ones work in the best effort mode the same way as they are now. Does that sound at least remotely reasonably? -- Michal Hocko SUSE Labs

WARNING: CPU: 0 PID: 3634 at drivers/gpu/drm/drm_irq.c:1141 drm_wait_one_vblank

2015-06-30 Thread Michal Hocko
"vblank wait timed out on crtc %i\n", crtc); -- Michal Hocko SUSE Labs

WARNING: CPU: 0 PID: 3634 at drivers/gpu/drm/drm_irq.c:1141 drm_wait_one_vblank

2015-06-30 Thread Michal Hocko
... > Also have you any special features like psr, fbc or something similar > enabled? I am not aware of anything like that. How do I check it? -- Michal Hocko SUSE Labs -- next part -- A non-text attachment was scrubbed... Name: dmesg.gz Type: application/gzip Size: 2

WARNING: CPU: 0 PID: 3634 at drivers/gpu/drm/drm_irq.c:1141 drm_wait_one_vblank

2015-06-30 Thread Michal Hocko
gt;dev); > } > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- Michal Hocko SUSE Labs -- next part -- A non-text attachment was scrubbed... Name: dmesg.gz Type: application/gzip Size: 25781 bytes Desc: not avail

WARNING: CPU: 0 PID: 3634 at drivers/gpu/drm/drm_irq.c:1141 drm_wait_one_vblank

2015-07-01 Thread Michal Hocko
On Wed 01-07-15 10:26:39, Daniel Vetter wrote: > On Tue, Jun 30, 2015 at 10:13:35PM +0200, Michal Hocko wrote: > > On Tue 30-06-15 18:59:29, Daniel Vetter wrote: [...] > > > Also it might be time to start bisecting this if you can readily > > > reproduce it. > >

WARNING: CPU: 0 PID: 3634 at drivers/gpu/drm/drm_irq.c:1141 drm_wait_one_vblank

2015-07-08 Thread Michal Hocko
ace, just to > understand a bit better what's going on there. And 0xf debug level seem to paper over the problem because I do not see the warning even with 4.1 where I am able to reproduce this reliably. This suggests this is a timing sensitive issue. -- Michal Hocko SUSE Labs

WARNING: CPU: 0 PID: 3634 at drivers/gpu/drm/drm_irq.c:1141 drm_wait_one_vblank

2015-07-08 Thread Michal Hocko
ernel log from both runs attached. -- Michal Hocko SUSE Labs -- next part -- A non-text attachment was scrubbed... Name: log.gz Type: application/gzip Size: 32451 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150708/53a1722

Linux 2.6.37

2011-01-06 Thread Michal Hocko
ecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- [disabled] Capabilities: Kernel driver in use: i915 [...] -- Michal Hocko L3 team SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic

Linux 2.6.37

2011-01-06 Thread Michal Hocko
Just for reference, my initial report was: https://lkml.org/lkml/2010/11/23/146 On Thu 06-01-11 08:29:22, Linus Torvalds wrote: > On Thu, Jan 6, 2011 at 2:48 AM, Michal Hocko wrote: > > > > It seems that there is still a regression for intel graphic cards > > backlight

Linux 2.6.37

2011-01-07 Thread Michal Hocko
??CC ?? ?? ??drivers/gpu/drm/i915/intel_lvds.o > > drivers/gpu/drm/i915/intel_lvds.c: In function ???intel_lvds_enable???: > > drivers/gpu/drm/i915/intel_lvds.c:110: error: ???PPS_STATUS??? undeclared > > Ah, I see. Should be PP_STATUS. Whatever. It does not help. The backlight > stays off. It didn't help in my case either -- Michal Hocko L3 team SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic

Linux 2.6.37

2011-01-11 Thread Michal Hocko
uot;vesa" or "fbcon" X11 driver, right? I seen same problem > until I switched to "intel" X11 driver). I am using intel X11 driver: [...] (II) Loading extension DRI2 (II) LoadModule: "intel" (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so [...] So this doesn't look like the case. -- Michal Hocko L3 team SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic

Linux 2.6.37

2011-01-11 Thread Michal Hocko
[Let's CC Indan - author of the bugzilla patches] On Thu 06-01-11 11:48:16, Michal Hocko wrote: > Hi, > > On Tue 04-01-11 17:15:45, Linus Torvalds wrote: > [...] > > We did have another revert to fix hopefullythe last "blank screen" > > regressio

Linux 2.6.37

2011-01-11 Thread Michal Hocko
On Tue 11-01-11 18:17:44, Michal Hocko wrote: > [Let's CC Indan - author of the bugzilla patches] > > On Thu 06-01-11 11:48:16, Michal Hocko wrote: > > Hi, > > > > On Tue 04-01-11 17:15:45, Linus Torvalds wrote: > > [...] > > > We did have another rev

Linux 2.6.37

2011-01-11 Thread Michal Hocko
On Tue 11-01-11 17:39:42, Chris Wilson wrote: > On Tue, 11 Jan 2011 18:19:17 +0100, Michal Hocko wrote: > > [Let's CC Indan - author of the bugzilla patches] > > > > On Thu 06-01-11 11:48:16, Michal Hocko wrote: > > > Hi, > > > > > >

Linux 2.6.37

2011-01-11 Thread Michal Hocko
On Tue 11-01-11 18:37:41, Michal Hocko wrote: > On Tue 11-01-11 18:17:44, Michal Hocko wrote: > > [Let's CC Indan - author of the bugzilla patches] > > > > On Thu 06-01-11 11:48:16, Michal Hocko wrote: > > > Hi, > > > > > > On Tue 04-01-11 17:15:

i915: display doesn't get on back after returning from standby in 2.6.27-rc*

2010-11-23 Thread Michal Hocko
915 [...] Nothing appears in the log during dpms standby and the lid close. dmesg output is attached. Config is attached as well. Let me know if you need further information. Thanks -- Michal Hocko L3 team SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic -- n

i915: display doesn't get on back after returning from standby in 2.6.27-rc*

2010-11-25 Thread Michal Hocko
[Let's add Rafael for regression tracking] On Tue 23-11-10 13:32:34, Michal Hocko wrote: > Hi, > since early 2.6.37 (I haven't bisected when exactly) my screen doesn't > get on after it got into standby mode. I have to either change to a > text console and back (if it get

[REGRESSION] [2.6.36-rc1] [DRM INTEL] [drm:intel_calculate_wm] *ERROR* Insufficient FIFO for plane, expect flickering: entries required = 36, available = 28.

2010-08-19 Thread Michal Hocko
\* //' | sort | uniq -c 49 Insufficient FIFO for plane, expect flickering: entries required = 36, available = 28. 33 Insufficient FIFO for plane, expect flickering: entries required = 36, available = 31. [...] [*] lspci and config attached Thanks -- Michal Hocko L3 team SU

[PATCH] hugetlb: release pages in the error path of hugetlb_cow() (was: Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1)

2011-11-28 Thread Michal Hocko
On Mon 21-11-11 14:18:29, Linus Torvalds wrote: > On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki wrote: > > > > Subject ? ?: hugetlb oops on 3.1.0-rc8-devel > > Submitter ?: Andy Lutomirski > > Date ? ? ? : 2011-11-01 22:20 > > Message-ID : CALCETrW1mpVCz2tO5roaz1r6vnno+srHR-dHA6_pkRi2qiCfdw

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

2017-03-06 Thread Michal Hocko
On Mon 06-03-17 11:40:41, Daniel Vetter wrote: > On Mon, Mar 06, 2017 at 08:42:59AM +0100, Michal Hocko wrote: > > On Fri 03-03-17 09:37:55, Laura Abbott wrote: > > > On 03/03/2017 05:29 AM, Michal Hocko wrote: > > > > On Thu 02-03-17 13:44:32, L

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

2017-03-06 Thread Michal Hocko
On Fri 03-03-17 09:37:55, Laura Abbott wrote: > On 03/03/2017 05:29 AM, Michal Hocko wrote: > > On Thu 02-03-17 13:44:32, Laura Abbott wrote: > >> Hi, > >> > >> There's been some recent discussions[1] about Ion-like frameworks. There's > >> apparentl

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

2017-03-05 Thread Michal Hocko
es to the ABI people might want. Once this comes out of staging, > I really don't want to mess with the ABI. Could you recapitulate concerns preventing the code being merged normally rather than through the staging tree and how they were addressed? -- Michal Hocko SUSE Labs __

nouveau driver locks up with 4.11 kernel

2017-08-14 Thread Michal Hocko
_ERROR 13 [] 1 nouveau :03:00.0: fifo: runlist update timeout 4249 nouveau :03:00.0: fifo: SCHED_ERROR 13 [] -- Michal Hocko SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: nouveau driver locks up with 4.11 kernel

2017-08-14 Thread Michal Hocko
On Mon 14-08-17 15:27:20, Ilia Mirkin wrote: > On Mon, Aug 14, 2017 at 3:18 PM, Michal Hocko <mho...@kernel.org> wrote: [...] > > nouveau :03:00.0: fifo: channel 6 [mpv/vo[3535]] kick timeout > > nouveau: mpv/vo[3535]::906f: detach gr failed, -110 &

Re: printk: Should console related code avoid __GFP_DIRECT_RECLAIM memory allocations?

2017-07-10 Thread Michal Hocko
. it's console semaphore > to blame, I think. Agreed! Looking at the problem just from the page allocator perspective is simply wrong. That is where you see your immediate problem because that is what you are testing I would bet my hat you can find other interesting scenarios if you try too hard..

GPU hangs and X shot down with 4.11-rc6

2017-04-25 Thread Michal Hocko
oes this ring bells? The GPU crash dump is attached in case it is useful. Let me know if you need additional information. Thanks! -- Michal Hocko SUSE Labs gpu_dump.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.

Re: [Intel-gfx] GPU hangs and X shot down with 4.11-rc6

2017-04-26 Thread Michal Hocko
On Tue 25-04-17 21:03:32, Chris Wilson wrote: > On Tue, Apr 25, 2017 at 06:41:20PM +0200, Michal Hocko wrote: > > Hi, > > I have just experienced X being shut down once with 4.11-rc2 and 2 times > > with 4.11-rc6 kernel. I do not remember seeing something like this >

Re: [PATCH] drm: use kvmalloc_array for drm_malloc*

2017-05-17 Thread Michal Hocko
On Tue 16-05-17 11:22:30, Daniel Vetter wrote: > On Tue, May 16, 2017 at 11:06:06AM +0200, Michal Hocko wrote: > > From: Michal Hocko <mho...@suse.com> > > > > drm_malloc* has grown their own kmalloc with vmalloc fallback > > implementations. MM has grown kvmallo

Re: [PATCH] drm: use kvmalloc_array for drm_malloc*

2017-05-17 Thread Michal Hocko
On Tue 16-05-17 10:31:19, Chris Wilson wrote: > On Tue, May 16, 2017 at 11:06:06AM +0200, Michal Hocko wrote: > > From: Michal Hocko <mho...@suse.com> > > > > drm_malloc* has grown their own kmalloc with vmalloc fallback > > implementations. MM has grown kvmallo

Re: [PATCH] drm: use kvmalloc_array for drm_malloc*

2017-05-17 Thread Michal Hocko
On Tue 16-05-17 12:09:08, Chris Wilson wrote: > On Tue, May 16, 2017 at 12:53:52PM +0200, Michal Hocko wrote: > > On Tue 16-05-17 10:31:19, Chris Wilson wrote: > > > On Tue, May 16, 2017 at 11:06:06AM +0200, Michal Hocko wrote: > > > > From:

[PATCH] drm: use kvmalloc_array for drm_malloc*

2017-05-17 Thread Michal Hocko
From: Michal Hocko <mho...@suse.com> drm_malloc* has grown their own kmalloc with vmalloc fallback implementations. MM has grown kvmalloc* helpers in the meantime. Let's use those because it a) reduces the code and b) MM has a better idea how to implement fallbacks (e.g. do not vmalloc

[PATCH 2/2] drm: drop drm_[cm]alloc* helpers

2017-05-17 Thread Michal Hocko
From: Michal Hocko <mho...@suse.com> Now that drm_[cm]alloc* helpers are simple one line wrappers around kvmalloc_array and drm_free_large is just kvfree alias we can drop them and replace by their native forms. This shouldn't introduce any functional change. Suggested-by: Daniel Vette

Re: [PATCH] drm: use kvmalloc_array for drm_malloc*

2017-05-17 Thread Michal Hocko
On Wed 17-05-17 08:59:44, Chris Wilson wrote: > On Wed, May 17, 2017 at 09:44:53AM +0200, Michal Hocko wrote: > > On Tue 16-05-17 12:09:08, Chris Wilson wrote: > > > On Tue, May 16, 2017 at 12:53:52PM +0200, Michal Hocko wrote: > > > > On Tue 16-05-17 10:31:19, Chris

[PATCH 1/2] drm: replace drm_[cm]alloc* by kvmalloc alternatives

2017-05-17 Thread Michal Hocko
From: Michal Hocko <mho...@suse.com> drm_[cm]alloc* has grown their own kvmalloc with vmalloc fallback implementations. MM has grown kvmalloc* helpers in the meantime. Let's use those because it a) reduces the code and b) MM has a better idea how to implement fallbacks (e.g. do not vmalloc

[PATCH 2/2 -v2] drm: drop drm_[cm]alloc* helpers

2017-05-17 Thread Michal Hocko
4a00b3ade5ca4514f7affd8de6f7119c8d5c5a86 Mon Sep 17 00:00:00 2001 From: Michal Hocko <mho...@suse.com> Date: Tue, 16 May 2017 11:00:47 +0200 Subject: [PATCH -v2] drm: drop drm_[cm]alloc* helpers Now that drm_[cm]alloc* helpers are simple one line wrappers around kvmalloc_array and drm_free

Re: [PATCH 1/2] drm: replace drm_[cm]alloc* by kvmalloc alternatives

2017-05-17 Thread Michal Hocko
On Wed 17-05-17 08:38:09, Chris Wilson wrote: > On Wed, May 17, 2017 at 08:55:08AM +0200, Michal Hocko wrote: > > From: Michal Hocko <mho...@suse.com> > > > > drm_[cm]alloc* has grown their own kvmalloc with vmalloc fallback > > implementations. MM has grown

Re: [PATCH] drm: use kvmalloc_array for drm_malloc*

2017-05-17 Thread Michal Hocko
On Tue 16-05-17 15:08:56, Daniel Vetter wrote: > On Tue, May 16, 2017 at 11:52:55AM +0200, Michal Hocko wrote: > > On Tue 16-05-17 11:22:30, Daniel Vetter wrote: > > > On Tue, May 16, 2017 at 11:06:06AM +0200, Michal Hocko wrote: > > > > From:

Re: [PATCH 1/2] drm: replace drm_[cm]alloc* by kvmalloc alternatives

2017-05-17 Thread Michal Hocko
On Wed 17-05-17 10:12:41, Chris Wilson wrote: > On Wed, May 17, 2017 at 11:03:50AM +0200, Michal Hocko wrote: [...] > > +static inline bool alloc_array_check(size_t n, size_t size) > > +{ > > + if (size != 0 && n > SIZE_MAX / size) > > + return

Re: [PATCH 1/3] drm/etnaviv: don't trigger OOM killer when page allocation fails

2017-06-26 Thread Michal Hocko
; > + __GFP_NORETRY | __GFP_NOWARN); > > > > > > _NORETRY means the mm does try hard at all to free memory. We've just done > > > this patch in 4.12 and totally regret it, because now gpu tasks run out of > > > memory with

Re: [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-07-02 Thread Michal Hocko
On Mon 02-07-18 11:14:58, Christian König wrote: > Am 27.06.2018 um 09:44 schrieb Michal Hocko: > > This is the v2 of RFC based on the feedback I've received so far. The > > code even compiles as a bonus ;) I haven't runtime tested it yet, mostly > > because I have no i

Re: [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-07-02 Thread Michal Hocko
On Mon 02-07-18 14:24:29, Christian König wrote: > Am 02.07.2018 um 14:20 schrieb Michal Hocko: > > On Mon 02-07-18 14:13:42, Christian König wrote: > > > Am 02.07.2018 um 13:54 schrieb Michal Hocko: > > > > On Mon 02-07-18 11:14:58, Christian König wrote: > >

Re: [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-07-02 Thread Michal Hocko
On Mon 02-07-18 14:13:42, Christian König wrote: > Am 02.07.2018 um 13:54 schrieb Michal Hocko: > > On Mon 02-07-18 11:14:58, Christian König wrote: > > > Am 27.06.2018 um 09:44 schrieb Michal Hocko: > > > > This is the v2 of RFC based on the feedback I've received

Re: [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-07-02 Thread Michal Hocko
would simply back of without releasing any memory. The patch should help to reclaim some memory. > But do you know a way to let the OOM killer kill a specific process? Yes, you can set its oom_score_adj to 1000 which means always select that task. -- M

Re: [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-06-25 Thread Michal Hocko
On Mon 25-06-18 10:01:03, Michal Hocko wrote: > On Fri 22-06-18 16:09:06, Felix Kuehling wrote: > > On 2018-06-22 11:24 AM, Michal Hocko wrote: > > > On Fri 22-06-18 17:13:02, Christian König wrote: > > >> Hi Michal, > > >> > > >> [Adding F

Re: [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-06-25 Thread Michal Hocko
On Fri 22-06-18 16:09:06, Felix Kuehling wrote: > On 2018-06-22 11:24 AM, Michal Hocko wrote: > > On Fri 22-06-18 17:13:02, Christian König wrote: > >> Hi Michal, > >> > >> [Adding Felix as well] > >> > >> Well first of all you have a miscon

Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-06-22 Thread Michal Hocko
[Resnding with the CC list fixed] On Fri 22-06-18 18:40:26, Michal Hocko wrote: > On Fri 22-06-18 12:18:46, Jerome Glisse wrote: > > On Fri, Jun 22, 2018 at 05:57:16PM +0200, Michal Hocko wrote: > > > On Fri 22-06-18 16:36:49, Chris Wilson wrote: > > > > Quoting Mic

Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-06-22 Thread Michal Hocko
[Hmm, the cc list got mangled somehow - you have just made many people to work for suse ;) and to kvack.org in the preious one - fixed up hopefully] On Fri 22-06-18 17:07:21, Chris Wilson wrote: > Quoting Michal Hocko (2018-06-22 16:57:16) > > On Fri 22-06-18 16:36:49, Chris Wil

Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-06-22 Thread Michal Hocko
On Fri 22-06-18 16:36:49, Chris Wilson wrote: > Quoting Michal Hocko (2018-06-22 16:02:42) > > Hi, > > this is an RFC and not tested at all. I am not very familiar with the > > mmu notifiers semantics very much so this is a crude attempt to achieve > > what I need basica

Re: [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-06-27 Thread Michal Hocko
2001 From: Michal Hocko Date: Wed, 20 Jun 2018 15:03:20 +0200 Subject: [PATCH] mm, oom: distinguish blockable mode for mmu notifiers MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit There are several blockable mmu notifiers which might sleep

Re: [RFC] Per file OOM badness

2018-01-19 Thread Michal Hocko
for almost anybody else. -- Michal Hocko SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Per file OOM badness

2018-01-19 Thread Michal Hocko
On Fri 19-01-18 13:13:51, Michal Hocko wrote: > On Fri 19-01-18 12:37:51, Christian König wrote: > [...] > > The per file descriptor badness is/was just the much easier approach to > > solve the issue, because the drivers already knew which client is currently > > us

Re: [RFC] Per file OOM badness

2018-01-19 Thread Michal Hocko
On Fri 19-01-18 09:39:03, Christian König wrote: > Am 19.01.2018 um 09:20 schrieb Michal Hocko: [...] > > OK, in that case I would propose a different approach. We already > > have rss_stat. So why do not we simply add a new counter there > > MM_KERNELPAGES and consider

Re: [RFC] Per file OOM badness

2018-01-19 Thread Michal Hocko
On Thu 18-01-18 12:01:32, Eric Anholt wrote: > Michal Hocko <mho...@kernel.org> writes: > > > On Thu 18-01-18 18:00:06, Michal Hocko wrote: > >> On Thu 18-01-18 11:47:48, Andrey Grodzovsky wrote: > >> > Hi, this series is a revised version of an RFC sent by

Re: [RFC] Per file OOM badness

2018-01-19 Thread Michal Hocko
thing rather specific to the particular subsytem. And my main objection here is that struct file is not a proper vehicle to carry such an information. So whatever the TTM subsystem does it should contribute to generic counters rather than abuse fd because it happens to use it to communicate with userspace. -- M

Re: [RFC] Per file OOM badness

2018-01-19 Thread Michal Hocko
e). Any better idea? I'm considering : to put a callback into file_ops instead. -- Michal Hocko SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Per file OOM badness

2018-01-19 Thread Michal Hocko
On Thu 18-01-18 18:00:06, Michal Hocko wrote: > On Thu 18-01-18 11:47:48, Andrey Grodzovsky wrote: > > Hi, this series is a revised version of an RFC sent by Christian König > > a few years ago. The original RFC can be found at > > https://lists.freedesktop.org/archives/dri

Re: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages

2018-01-30 Thread Michal Hocko
On Tue 30-01-18 11:32:49, Christian König wrote: > Am 30.01.2018 um 11:18 schrieb Michal Hocko: > > On Tue 30-01-18 10:00:07, Christian König wrote: > > > Am 30.01.2018 um 08:55 schrieb Michal Hocko: > > > > On Tue 30-01-18 02:56:51, He, Roger wrote: > > >

Re: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages

2018-01-29 Thread Michal Hocko
BOL_GPL(get_total_swap_pages); > + > static inline unsigned char swap_count(unsigned char ent) > { > return ent & ~SWAP_HAS_CACHE; /* may include SWAP_HAS_CONT flag */ > -- > 2.7.4 -- Michal Hocko SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages

2018-02-01 Thread Michal Hocko
ory pressure. There are other users of memory on the system other than your subsystem. -- Michal Hocko SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages

2018-01-30 Thread Michal Hocko
On Tue 30-01-18 10:00:07, Christian König wrote: > Am 30.01.2018 um 08:55 schrieb Michal Hocko: > > On Tue 30-01-18 02:56:51, He, Roger wrote: > > > Hi Michal: > > > > > > We need a API to tell TTM module the system totally has how many swap > > > c

Re: [RFC] Per file OOM badness

2018-01-30 Thread Michal Hocko
On Tue 30-01-18 10:29:10, Michel Dänzer wrote: > On 2018-01-24 12:50 PM, Michal Hocko wrote: > > On Wed 24-01-18 12:23:10, Michel Dänzer wrote: > >> On 2018-01-24 12:01 PM, Michal Hocko wrote: > >>> On Wed 24-01-18 11:27:15, Michel Dänzer wrote: > > [..

Re: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages

2018-01-29 Thread Michal Hocko
module now. It can't cover the case of the dynamic swap size > increment. I mean: user can use "swapon" to enable new swap file or > swap disk dynamically or "swapoff" to disable swap space. Exactly. Your scaling configuration based on get_nr_swap_pages or the available m

  1   2   >