On 6/7/23 16:20, Miklos Szeredi wrote:
On Thu, 23 Mar 2023 at 12:55, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
On Thu, Mar 23, 2023 at 1:18 PM Bernd Schubert
<bernd.schubert@xxxxxxxxxxx> wrote:
there were several zufs threads, but I don't remember discussions about
cache line - maybe I had missed it. I can try to read through the old
threads, in case you don't have it.
Miklos talked about it somewhere...
It was a private exchange between Amir and me:
On Tue, 25 Feb 2020 at 20:33, Miklos Szeredi <miklos@xxxxxxxxxx> wrote
> On Tue, Feb 25, 2020 at 6:49 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote:
[...]
> > BTW, out of curiosity, what was the purpose of the example of
> > "use shared memory instead of threads"?
>
> In the threaded case there's a shared piece of memory in the kernel
> (mm->cpu_bitmap) that is updated on each context switch (i.e. each
> time a request is processed by one of the server threads). If this is
> a big NUMA system then cacheline pingpong on this bitmap can be a real
> performance hit.
>
> Using shared memory means that the address space is not shared, hence
> each server "thread" will have a separate "mm" structure, hence no
> cacheline pingpong.
>
> It would be nice if the underlying problem with shared address space
> could be solved in a scalable way instead of having to resort to this
> hack, but it's not a trivial thing to do. If you look at the
> scheduler code, there's already a workaround for this issue in the
> kernel threads case, but that doesn't work for user threads.
Ah, thank you! I can quote this mail here then for the next version.
Thanks,
Bernd
PS: I get currently distracted by other work, I hope I can get back to
fuse by tomorrow.