Messages in this thread | | | Subject | Re: [PATCH 5/8] x86/clear_page: add clear_page_uncached() | From | Ankur Arora <> | Date | Wed, 14 Oct 2020 20:37:44 -0700 |
| |
On 2020-10-14 2:12 p.m., Borislav Petkov wrote: > On Wed, Oct 14, 2020 at 02:07:30PM -0700, Andy Lutomirski wrote: >> I assume it’s for a little optimization of clearing more than one >> page per SFENCE. >> >> In any event, based on the benchmark data upthread, we only want to do >> NT clears when they’re rather large, so this shouldn’t be just an >> alternative. I assume this is because a page or two will fit in cache >> and, for most uses that allocate zeroed pages, we prefer cache-hot >> pages. When clearing 1G, on the other hand, cache-hot is impossible >> and we prefer the improved bandwidth and less cache trashing of NT >> clears. > > Yeah, use case makes sense but people won't know what to use. At the > time I was experimenting with this crap, I remember Linus saying that > that selection should be made based on the size of the area cleared, so > users should not have to know the difference. I don't disagree but I think the selection of cached/uncached route should be made where we have enough context available to be able to choose to do this.
This could be for example, done in mm_populate() or gup where if say the extent is larger than LLC-size, it takes the uncached path.
> > Which perhaps is the only sane use case I see for this. > >> Perhaps SFENCE is so fast that this is a silly optimization, though, >> and we don’t lose anything measurable by SFENCEing once per page. > > Yes, I'd like to see real use cases showing improvement from this, not > just microbenchmarks. Sure will add.
Thanks Ankur
>
| |