Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1623739

Re: [PATCH] padata: allow caller to control queue length

From "Jason A. Donenfeld" <Jason@zx2c4.com>
Newsgroups linux.kernel
Subject Re: [PATCH] padata: allow caller to control queue length
Date 2017-04-14 17:50 +0200
Message-ID <twbDY-2Q9-35@gated-at.bofh.it> (permalink)
References <tvJHI-18N-17@gated-at.bofh.it> <tw4j7-6OJ-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Fri, Apr 14, 2017 at 9:57 AM, Steffen Klassert
<steffen.klassert@secunet.com> wrote:
> Why do we need this? As long as we don't have a user that needs a
> different limit, this patch adds just some useless code.

My [not-yet-mainlined] code wants it.

But more compellingly, padata simply isn't a very useful interface if
it contains random limits like that. Different consumers will want
different things. Pcrypt has been the only consumer for years and
years, despite it being in kernel/; it's probably a good idea to
figure out how to make this more attractive in general, since parallel
processing is a useful thing. The 1000 job limit is particularly
annoying for systems with tons and tons of cores; here you'd want the
ability for more jobs to be allowed at a time.

I'm also open to discussing other ways to handle limiting. But a hard
coded random number of 1000 seems wrong.

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH] padata: allow caller to control queue length "Jason A. Donenfeld" <Jason@zx2c4.com> - 2017-04-13 12:00 +0200
  Re: [PATCH] padata: allow caller to control queue length Steffen Klassert <steffen.klassert@secunet.com> - 2017-04-14 10:00 +0200
    Re: [PATCH] padata: allow caller to control queue length "Jason A. Donenfeld" <Jason@zx2c4.com> - 2017-04-14 17:50 +0200
      Re: [PATCH] padata: allow caller to control queue length Herbert Xu <herbert@gondor.apana.org.au> - 2017-04-18 12:50 +0200

csiph-web