On Wed, Feb 10, 2021 at 01:59:13PM -0400, Jason Gunthorpe wrote:
> Really what you want to do here is leave the CPU page in the VMA and
> the page tables where it started and deny CPU access to the page. Then
> all the proper machinery will continue to work.
>
> IMHO "migration" is the wrong idea
On Mon, Feb 08, 2021 at 06:39:00PM -0500, Lyude Paul wrote:
> Since we're about to implement eDP backlight support in nouveau using the
> standard protocol from VESA, we might as well just take the code that's
> already written for this and move it into a set of shared DRM helpers.
>
> Note that t
On Mon, Feb 08, 2021 at 06:38:55PM -0500, Lyude Paul wrote:
> Get rid of the extraneous switch case in here, and just open code
> edp_backlight_mode as we only ever use it once.
>
> v4:
> * Check that backlight mode is DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD, not
> DP_EDP_BACKLIGHT_CONTROL_MODE_MASK
On Mon, Feb 08, 2021 at 06:38:58PM -0500, Lyude Paul wrote:
> If we can't read DP_EDP_PWMGEN_BIT_COUNT in
> intel_dp_aux_vesa_calc_max_backlight() but do have a valid PWM frequency
> defined in the VBT, we'll keep going in the function until we inevitably
> fail on reading DP_EDP_PWMGEN_BIT_COUNT_C
On Mon, Feb 08, 2021 at 06:38:59PM -0500, Lyude Paul wrote:
> Also, stop printing the DPCD register that failed, and just describe it
> instead. Saves us from having to look up each register offset when reading
> through kernel logs (plus, DPCD dumping with drm.debug |= 0x100 will give
> us that an
On 2/10/21 4:59 AM, Daniel Vetter wrote:
...
GPU atomic operations to sysmem are hard to categorize, because because
application
programmers could easily write programs that do a long series of atomic
operations.
Such a program would be a little weird, but it's hard to rule out.
Yeah, but we
On Tue, Feb 09, 2021 at 12:53:27PM -0800, John Hubbard wrote:
> This direction sounds at least...possible. Using MMU notifiers instead of pins
> is definitely appealing. I'm not quite clear on the callback idea above, but
> overall it seems like taking advantage of the ZONE_DEVICE tracking of page
On Tue, Feb 09, 2021 at 04:17:38PM -0500, Jerome Glisse wrote:
> > > Yes, I would like to avoid the long term pin constraints as well if
> > > possible I
> > > just haven't found a solution yet. Are you suggesting it might be
> > > possible to
> > > add a callback in the page migration logic to
On Wed, 2021-02-10 at 16:34 +0100, Christian König wrote:
> Any objections that I add a Reported-and-tested-by: Mike Galbraith
> ?
Fine by me.
-Mike
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/l
Am 10.02.21 um 16:30 schrieb Mike Galbraith:
On Wed, 2021-02-10 at 14:26 +0100, Christian König wrote:
Am 10.02.21 um 13:22 schrieb Mike Galbraith:
On Wed, 2021-02-10 at 12:44 +0100, Christian König wrote:
Please try to add a "return NULL" at the beginning of ttm_pool_type_take().
That sho
On Wed, 2021-02-10 at 14:26 +0100, Christian König wrote:
>
> Am 10.02.21 um 13:22 schrieb Mike Galbraith:
> > On Wed, 2021-02-10 at 12:44 +0100, Christian König wrote:
> >> Please try to add a "return NULL" at the beginning of ttm_pool_type_take().
> >>
> >> That should effectively disable using t
Am 10.02.21 um 13:22 schrieb Mike Galbraith:
On Wed, 2021-02-10 at 12:44 +0100, Christian König wrote:
Please try to add a "return NULL" at the beginning of ttm_pool_type_take().
That should effectively disable using the pool.
That did away with the yield looping, but it doesn't take long fo
On Wed, Feb 10, 2021 at 08:45:56AM +0100, Christian König wrote:
> Reviewed-by: Christian König for the series.
Smash it into -misc?
-Daniel
>
> Am 10.02.21 um 00:48 schrieb Rikard Falkeborn:
> > Constify a few static vm_operations_struct that are never modified. Their
> > only usage is to assi
On Tue, Feb 09, 2021 at 12:53:27PM -0800, John Hubbard wrote:
> On 2/9/21 5:37 AM, Daniel Vetter wrote:
> > On Tue, Feb 9, 2021 at 1:57 PM Alistair Popple wrote:
> > >
> > > On Tuesday, 9 February 2021 9:27:05 PM AEDT Daniel Vetter wrote:
> > > > >
> > > > > Recent changes to pin_user_pages() pr
On Wed, Feb 10, 2021 at 02:40:10PM +1100, Alistair Popple wrote:
> On Wednesday, 10 February 2021 12:39:32 AM AEDT Jason Gunthorpe wrote:
> > On Tue, Feb 09, 2021 at 12:07:14PM +1100, Alistair Popple wrote:
> > > Device private pages are used to represent device memory that is not
> > > directly ac
On Wed, 2021-02-10 at 12:44 +0100, Christian König wrote:
> Please try to add a "return NULL" at the beginning of ttm_pool_type_take().
>
> That should effectively disable using the pool.
That did away with the yield looping, but it doesn't take long for the
display to freeze. I ssh'd in from lap
Constify a few static vm_operations_struct that are never modified. Their
only usage is to assign their address to the vm_ops field in the
vm_area_struct, which is a pointer to const vm_operations_struct. Make them
const to allow the compiler to put them in read-only memory.
With this series appli
The only usage of radeon_ttm_vm_ops is to assign its address to the
vm_ops field in the vm_area_struct struct. Make it const to allow the
compiler to put it in read-only memory
Signed-off-by: Rikard Falkeborn
---
drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 delet
The only usage of amdgpu_ttm_vm_ops is to assign its address to the
vm_ops field in the vm_area_struct struct. Make it const to allow the
compiler to put it in read-only memory.
Signed-off-by: Rikard Falkeborn
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1
The only usage of nouveau_ttm_vm_ops is to assign its address to the
vm_ops field in the vm_area_struct struct. Make it const to allow the
compiler to put it in read-only memory
Signed-off-by: Rikard Falkeborn
---
drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 de
Please try to add a "return NULL" at the beginning of ttm_pool_type_take().
That should effectively disable using the pool.
Thanks for testing,
Christian.
Am 10.02.21 um 12:22 schrieb Mike Galbraith:
On Wed, 2021-02-10 at 11:52 +0100, Christian König wrote:
You could try to replace the "for
On Wed, 2021-02-10 at 11:52 +0100, Christian König wrote:
>
>
> You could try to replace the "for (order = min(MAX_ORDER - 1UL,
> __fls(num_pages)); num_pages;" in ttm_pool_alloc() with "for (order = 0;
> num_pages;" to get the old behavior.
That's a nogo too.
-Mike
_
On Wed, 2021-02-10 at 11:42 +0100, Christian König wrote:
>
> Am 10.02.21 um 11:40 schrieb Mike Galbraith:
> > On Wed, 2021-02-10 at 11:34 +0100, Christian König wrote:
> >> Hi Mike,
> >>
> >> do you have more information than just system stuck in a loop?
> > No, strace shows no syscalls but sched_
Am 10.02.21 um 11:46 schrieb Mike Galbraith:
On Wed, 2021-02-10 at 11:34 +0100, Christian König wrote:
What seems to happen here is that your system is low on resources and we
just try to free up pages.
FWIW, box has oodles generic ram free right after boot.
Then I have no idea what happen
On Wed, 2021-02-10 at 11:34 +0100, Christian König wrote:
> Hi Mike,
>
> do you have more information than just system stuck in a loop?
No, strace shows no syscalls but sched_yield().
-Mike
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
On Wed, 2021-02-10 at 11:34 +0100, Christian König wrote:
>
> What seems to happen here is that your system is low on resources and we
> just try to free up pages.
FWIW, box has oodles generic ram free right after boot.
-Mike
___
Nouveau mailin
Am 10.02.21 um 11:40 schrieb Mike Galbraith:
On Wed, 2021-02-10 at 11:34 +0100, Christian König wrote:
Hi Mike,
do you have more information than just system stuck in a loop?
No, strace shows no syscalls but sched_yield().
Well you can try to comment out the call to register_shrinker() in
Hi Mike,
do you have more information than just system stuck in a loop?
What seems to happen here is that your system is low on resources and we
just try to free up pages.
Previously the allocation would just have failed with an out of memory
condition.
Regards,
Christian.
Am 10.02.21 um
Greetings,
The symptom is tasks stuck waiting for lord knows what by calling
sched_yield() in a loop (less than wonderful, sched_yield() sucks).
After boot to KDE login, I immediately see tracker-extract chewing cpu
in aforementioned loop. Firing up evolution and poking 'new' to
compose, WebKitWeb
29 matches
Mail list logo
