linux-kernel - Re: read() syscall slowing down due to other threads?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4FA17F6A.9000606@genband.com>
Date:	Wed, 02 May 2012 12:39:38 -0600
From:	Chris Friesen <chris.friesen@...band.com>
To:	George Porter <gmporter@...ucsd.edu>
CC:	linux-kernel@...r.kernel.org
Subject: Re: read() syscall slowing down due to other threads?

On 05/01/2012 12:03 AM, George Porter wrote:

> However, if I start doing more computation on those other threads, the
> read() syscalls take longer to read the same amount of data,
> eventually slowing down to 50 MBps (50% slower).  I've used
> setaffinity() to isolate the Reader threads to one set of cores, and
> the compute threads to a different set of cores, and so I don't think
> it is CPU/scheduling interference.
>
> Thoughts?  Has anyone run into this before?

If you're using hyperthreading you may want to try it with either 
putting the computation threads on the siblings of the cpus for the 
reader threads (to share cache) or else not on the siblings of the cpus 
for the reader threads (to minimize contention of cpu resources).

Similarly, you may want to play with wither or not the threads are on 
the same or different sockets.

Chris

-- 
Chris Friesen
Software Developer
GENBAND
chris.friesen@...band.com
www.genband.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/