lkml.org 
[lkml]   [2023]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 7/9] sched: define TIF_ALLOW_RESCHED
On Mon, Sep 11, 2023 at 01:50:53PM -0700, Linus Torvalds wrote:
> Another example of this this is just plain read/write. It's not a
> problem in practice right now, because large pages are effectively
> never used.
>
> But just imagine what happens once filemap_read() actually does big folios?
>
> Do you really want this code:
>
> copied = copy_folio_to_iter(folio, offset, bytes, iter);
>
> to forever use the artificial chunking it does now?
>
> And yes, right now it will still do things in one-page chunks in
> copy_page_to_iter(). It doesn't even have cond_resched() - it's
> currently in the caller, in filemap_read().

Ah, um. If you take a look in fs/iomap/buffered-io.c, you'll
see ...

iomap_write_iter:
size_t chunk = PAGE_SIZE << MAX_PAGECACHE_ORDER;
struct folio *folio;
bytes = min(chunk - offset, iov_iter_count(i));
if (unlikely(fault_in_iov_iter_readable(i, bytes) == bytes)) {
copied = copy_folio_from_iter_atomic(folio, offset, bytes, i);

So we do still cond_resched(), but we might go up to PMD_SIZE
between calls. This is new code in 6.6 so it hasn't seen use by too
many users yet, but it's certainly bigger than the 16 pages used by
copy_chunked_from_user(). I honestly hadn't thought about preemption
latency.

\
 
 \ /
  Last update: 2023-09-12 05:43    [W:0.339 / U:2.352 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site