Re: [Nouveau] [PATCH RESEND][next] drm/nouveau/clk: Fix fall-through warnings for Clang
Hi all, If you don't mind, I'm taking this in my -next[1] branch for v5.14. Thanks -- Gustavo [1] https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git/log/?h=for-next/kspp On 6/1/21 17:57, Gustavo A. R. Silva wrote: > Hi, > > Friendly second ping: who can take this? > > I can add this to my -next branch for 5.14 if you don't mind. > > JFYI: We had thousands of these sorts of warnings and now we are down > to just 23 in linux-next. This is one of those last remaining warnings. > > Thanks > -- > Gustavo > > On 4/20/21 15:13, Gustavo A. R. Silva wrote: >> Hi all, >> >> Friendly ping: who can take this, please? >> >> Thanks >> -- >> Gustavo >> >> On 3/5/21 03:56, Gustavo A. R. Silva wrote: >>> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning >>> by explicitly adding a break statement instead of letting the code fall >>> through to the next case. >>> >>> Link: https://github.com/KSPP/linux/issues/115 >>> Signed-off-by: Gustavo A. R. Silva >>> --- >>> drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c >>> b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c >>> index 83067763c0ec..e1d31c62f9ec 100644 >>> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c >>> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c >>> @@ -313,6 +313,7 @@ nv50_clk_read(struct nvkm_clk *base, enum nv_clk_src >>> src) >>> default: >>> break; >>> } >>> + break; >>> default: >>> break; >>> } >>> ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH RESEND][next] drm/nouveau: Fix fall-through warnings for Clang
On 6/1/21 19:10, Karol Herbst wrote: > all three nouveau patches are > > Reviewed-by: Karol Herbst > > and I don't think anybody would mind if those get into through other > trees, but maybe drm-mist would be a good place for it if other > patches involve other drm drivers? No other person has replied after pinging multiple times and resending these patches, so I guess people don't care. I'll add this and the other similar patches to my -next branch for 5.14. Thanks, Karol. -- Gustavo > > On Wed, Jun 2, 2021 at 1:16 AM Gustavo A. R. Silva > wrote: >> >> Hi, >> >> Friendly second ping: who can take this? >> >> I can add this to my -next branch for 5.14 if you don't mind. >> >> JFYI: We had thousands of these sorts of warnings and now we are down >> to just 23 in linux-next. This is one of those last remaining warnings. >> >> Thanks >> -- >> Gustavo >> >> On 4/20/21 15:13, Gustavo A. R. Silva wrote: >>> Hi all, >>> >>> Friendly ping: who can take this, please? >>> >>> Thanks >>> -- >>> Gustavo >>> >>> On 3/5/21 03:56, Gustavo A. R. Silva wrote: In preparation to enable -Wimplicit-fallthrough for Clang, fix a couple of warnings by explicitly adding a couple of break statements instead of letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Signed-off-by: Gustavo A. R. Silva --- drivers/gpu/drm/nouveau/nouveau_bo.c| 1 + drivers/gpu/drm/nouveau/nouveau_connector.c | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index 2375711877cf..62903c3b368d 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c @@ -443,6 +443,7 @@ nouveau_bo_pin(struct nouveau_bo *nvbo, uint32_t domain, bool contig) break; case TTM_PL_TT: error |= !(domain & NOUVEAU_GEM_DOMAIN_GART); +break; default: break; } diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c index 61e6d7412505..eb844cdcaec2 100644 --- a/drivers/gpu/drm/nouveau/nouveau_connector.c +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c @@ -157,6 +157,7 @@ nouveau_conn_atomic_set_property(struct drm_connector *connector, default: break; } +break; case DRM_MODE_SCALE_FULLSCREEN: case DRM_MODE_SCALE_CENTER: case DRM_MODE_SCALE_ASPECT: >> ___ >> Nouveau mailing list >> Nouveau@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/nouveau >> > ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH RESEND][next] drm/nouveau/therm: Fix fall-through warnings for Clang
Hi all, If you don't mind, I'm taking this in my -next[1] branch for v5.14. Thanks -- Gustavo [1] https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git/log/?h=for-next/kspp On 6/1/21 17:58, Gustavo A. R. Silva wrote: > Hi, > > Friendly second ping: who can take this? > > I can add this to my -next branch for 5.14 if you don't mind. > > JFYI: We had thousands of these sorts of warnings and now we are down > to just 23 in linux-next. This is one of those last remaining warnings. > > Thanks > -- > Gustavo > > On 4/20/21 15:13, Gustavo A. R. Silva wrote: >> Hi all, >> >> Friendly ping: who can take this, please? >> >> Thanks >> -- >> Gustavo >> >> On 3/5/21 03:58, Gustavo A. R. Silva wrote: >>> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning >>> by explicitly adding a break statement instead of letting the code fall >>> through to the next case. >>> >>> Link: https://github.com/KSPP/linux/issues/115 >>> Signed-off-by: Gustavo A. R. Silva >>> --- >>> drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c >>> b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c >>> index 2b031d4eaeb6..684aff7437ee 100644 >>> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c >>> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c >>> @@ -41,6 +41,7 @@ pwm_info(struct nvkm_therm *therm, int line) >>> default: >>> break; >>> } >>> + break; >>> default: >>> break; >>> } >>> ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v9 07/10] mm: Device exclusive memory access
On Friday, 4 June 2021 12:47:40 AM AEST Peter Xu wrote:
> External email: Use caution opening links or attachments
>
> On Thu, Jun 03, 2021 at 09:39:32PM +1000, Alistair Popple wrote:
> > Reclaim won't run on the page due to the extra references from the special
> > swap entries.
>
> That sounds reasonable, but I didn't find the point that stops it, probably
> due to my limited knowledge on the reclaim code. Could you elaborate?
Sure, it isn't immediately obvious but it ends up being detected at the start
of is_page_cache_freeable() in the pageout code:
static pageout_t pageout(struct page *page, struct address_space *mapping)
{
[...]
if (!is_page_cache_freeable(page))
return PAGE_KEEP;
- Alistair
> --
> Peter Xu
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v9 07/10] mm: Device exclusive memory access
On Thursday, 3 June 2021 12:37:30 AM AEST Peter Xu wrote: > External email: Use caution opening links or attachments > > On Wed, Jun 02, 2021 at 06:50:37PM +1000, Balbir Singh wrote: > > On Wed, May 26, 2021 at 12:17:18AM -0700, John Hubbard wrote: > > > On 5/25/21 4:51 AM, Balbir Singh wrote: > > > ... > > > > > > > > How beneficial is this code to nouveau users? I see that it permits > > > > > a > > > > > part of OpenCL to be implemented, but how useful/important is this > > > > > in > > > > > the real world? > > > > > > > > That is a very good question! I've not reviewed the code, but a sample > > > > program with the described use case would make things easy to parse. > > > > I suspect that is not easy to build at the moment? > > > > > > The cover letter says this: > > > > > > This has been tested with upstream Mesa 21.1.0 and a simple OpenCL > > > program > > > which checks that GPU atomic accesses to system memory are atomic. > > > Without > > > this series the test fails as there is no way of write-protecting the > > > page > > > mapping which results in the device clobbering CPU writes. For reference > > > the test is available at https://ozlabs.org/~apopple/opencl_svm_atomics/ > > > > > > Further testing has been performed by adding support for testing > > > exclusive > > > access to the hmm-tests kselftests. > > > > > > ...so that seems to cover the "sample program" request, at least. > > > > Thanks, I'll take a look > > > > > > I wonder how we co-ordinate all the work the mm is doing, page > > > > migration, > > > > reclaim with device exclusive access? Do we have any numbers for the > > > > worst > > > > case page fault latency when something is marked away for exclusive > > > > access? > > > > > > CPU page fault latency is approximately "terrible", if a page is > > > resident on the GPU. We have to spin up a DMA engine on the GPU and > > > have it copy the page over the PCIe bus, after all. > > > > > > > I presume for now this is anonymous memory only? SWP_DEVICE_EXCLUSIVE > > > > would > > > > > > Yes, for now. > > > > > > > only impact the address space of programs using the GPU. Should the > > > > exclusively marked range live in the unreclaimable list and recycled > > > > back to active/in-active to account for the fact that > > > > > > > > 1. It is not reclaimable and reclaim will only hurt via page faults? > > > > 2. It ages the page correctly or at-least allows for that possibility > > > > when the> > > > > > > page is used by the GPU. > > > > > > I'm not sure that that is *necessarily* something we can conclude. It > > > depends upon access patterns of each program. For example, a > > > "reduction" parallel program sends over lots of data to the GPU, and > > > only a tiny bit of (reduced!) data comes back to the CPU. In that case, > > > freeing the physical page on the CPU is actually the best decision for > > > the OS to make (if the OS is sufficiently prescient).> > > With a shared device or a device exclusive range, it would be good to get > > the device usage pattern and update the mm with that knowledge, so that > > the LRU can be better maintained. With your comment you seem to suggest > > that a page used by the GPU might be a good candidate for reclaim based > > on the CPU's understanding of the age of the page should not account for > > use by the device > > (are GPU workloads - access once and discard?) > > Hmm, besides the aging info, this reminded me: do we need to isolate the > page from lru too when marking device exclusive access? > > Afaict the current patch didn't do that so I think it's reclaimable. If we > still have the rmap then we'll get a mmu notify CLEAR when unmapping that > special pte, so device driver should be able to drop the ownership. However > we dropped the rmap when marking exclusive. Now I don't know whether and > how it'll work if page reclaim runs with the page being exclusively owned > if without isolating the page.. Reclaim won't run on the page due to the extra references from the special swap entries. > -- > Peter Xu ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v9 07/10] mm: Device exclusive memory access
On 6/2/21 1:50 AM, Balbir Singh wrote: ... only impact the address space of programs using the GPU. Should the exclusively marked range live in the unreclaimable list and recycled back to active/in-active to account for the fact that 1. It is not reclaimable and reclaim will only hurt via page faults? 2. It ages the page correctly or at-least allows for that possibility when the page is used by the GPU. I'm not sure that that is *necessarily* something we can conclude. It depends upon access patterns of each program. For example, a "reduction" parallel program sends over lots of data to the GPU, and only a tiny bit of (reduced!) data comes back to the CPU. In that case, freeing the physical page on the CPU is actually the best decision for the OS to make (if the OS is sufficiently prescient). With a shared device or a device exclusive range, it would be good to get the device usage pattern and update the mm with that knowledge, so that the LRU can be better Integrating a GPU (or "device") processor and it's mm behavior with the Linux kernel is always an interesting concept. Certainly worth exploring, although it's probably not a small project by any means. maintained. With your comment you seem to suggest that a page used by the GPU might be a good candidate for reclaim based on the CPU's understanding of the age of the page should not account for use by the device (are GPU workloads - access once and discard?) Well, that's a little too narrow of an interpretation. The GPU is a fairly general purpose processor, and so it has all kinds of workloads. I'm trying to discourage any hopes that one can know, in advance, precisely how the GPU's pages need to be managed. It's similar to the the CPU, in that regard. My example was just one, out of a vast pool of possible behaviors. thanks, -- John Hubbard NVIDIA ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
