On Tue, Oct 27, 2020 at 04:10:44PM +1100, Dave Chinner wrote:
> On Wed, Oct 21, 2020 at 11:11:00PM -0700, Darrick J. Wong wrote:
> > On Thu, Oct 22, 2020 at 04:15:34PM +1100, Dave Chinner wrote:
> > > +static void
> > > +traverse_function(
> > > + struct workqueue *wq,
> > > + xfs_agnumber_t agno,
> > > + void *arg)
> > > +{
> > > + struct ino_tree_node *irec;
> > > prefetch_args_t *pf_args = arg;
> > > + struct workqueue lwq;
> > > + struct xfs_mount *mp = wq->wq_ctx;
> > > +
> > >
> > > wait_for_inode_prefetch(pf_args);
> > >
> > > if (verbose)
> > > do_log(_(" - agno = %d\n"), agno);
> > >
> > > + /*
> > > + * The more AGs we have in flight at once, the fewer processing threads
> > > + * per AG. This means we don't overwhelm the machine with hundreds of
> > > + * threads when we start acting on lots of AGs at once. We just want
> > > + * enough that we can keep multiple CPUs busy across multiple AGs.
> > > + */
> > > + workqueue_create_bound(&lwq, mp, ag_stride, 1000);
> >
> > Eeeeee, magic number! :)
> >
> > /me tosses in obligatory hand-wringing about 2000 CPU systems running
> > out of work. How about ag_stride * 50 or something? :P
>
> ag_stride already determines concurrency via how many AGs are being
> scanned at once. However, it provides no insight into the depth of
> the queue we need to use per AG.
>
> What this magic number does is bound how deep the work queue gets
> before we ask another worker thread to start also processing the
> queue.
It does? I didn't think we'd wake up extra worker threads when the
queue depth reached max_queued:
if (wq->max_queued && wq->next_item) {
/* more work, wake up another worker */
pthread_cond_signal(&wq->wakeup);
}
AFAICT, any time a worker dequeues a work item, observes that we have
a max queue depth, and sees that there's still more work to do, it'll
wake up another worker.
TBH I think this is better for cpu utilization because we should never
have idle workers while there's more work to do. At least for the scrub
case...
<shrug> Either that or I think I've misunderstood something?
> We've already got async threads doing inode prefetch, so the
> bound here throttles the rate at which inodes are
> prefetched into the buffer cache. In general, we're going to be IO
> bound and waiting on readahead rather than throttling on processing
> the inodes, so all this bound is doing is preventing readahead from
> running too far ahead of processing and potentially causing cache
> thrashing.
>
> However, we don't want to go using lots of threads to parallelise
> the work within the AG when we have already parallelised across AGs.
> We want the initial worker thread per AG to just keep working away
> burning CPU while the prefetch code is blocking waiting for more
> inodes from disk. Then we get another burst of work being queued,
> and so on.
> Hence the queue needs to be quite deep so that we can soak up the
> bursts of processing that readahead triggers without asking lots of
> worker threads to do work. However, if the worker thread hits some
> big directories and starts falling behind readahead, that's when it
> will hit the maximum queue depth and kick another thread to do work.
...ah, I think I grok the differences between what repair and scrub are
trying to do with the workqueue. Repair reaadahead is driving
workqueue_add() calls, so you don't really want to increase parallelism
of the workqueue until (a) you can be reasonably certain that the
workers won't block on IO and (b) the workers have bogged down on huge
directories such that the buffer cache is filling up with memory that
has no immediate consumer.
It's a little different from what I'm doing with scrub, which
effectively reads inobt records and queues each of them separately for
processing. In this case, the queue depth merely restrains our work
item memory allocations.
> IOWs, the queue depth needs to be deep enough to prevent bursts from
> triggering extra workers from running, but shallow enough that extra
> workers will be scheduled when processing falls behind readahead.
>
> I really don't have a good way to automatically calculate this
> depth. I just figure that if we have a 1000 inodes queued up for
> processing, we really should kick another thread to start working on
> them. It's a simple solution, so I'd like to see if we have problems
> with this simple threshold before we try to replace the magic number
> with a magic heuristic....
Hm, in that case, shouldn't that code snippet above read:
if (wq->max_queued && wq->item_count == wq->max_queued - 1) {
/* more work, wake up another worker */
pthread_cond_signal(&wq->wakeup);
}
That would seem to wake up another worker, but only after 1000 inodes
have been added to the queue.
--D
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@xxxxxxxxxxxxx
