From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Subject: Re: fio 3.2 References: <0e2efc36-3c1b-ac51-4baf-044276cc51e9@kernel.dk> From: Jens Axboe Message-ID: <5b1cd1e7-8a7a-033d-e962-e0df334a02d6@kernel.dk> Date: Sun, 3 Dec 2017 10:10:36 -0700 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit To: Sitsofe Wheeler , "Robert Elliott (Persistent Memory)" Cc: "Gavriliuk, Anton (HPS Ukraine)" , Rebecca Cran , "fio@vger.kernel.org" , "Kani, Toshimitsu" List-ID: On 12/03/2017 02:35 AM, Sitsofe Wheeler wrote: > On 1 December 2017 at 07:15, Robert Elliott (Persistent Memory) > wrote: >> While discussing NUMA, I'll mention something else I saw in Windows >> while fixing the thread affinities there. >> >> At startup, fio spawns threads on all CPUs to measure the clocks >> (fio_monotonic_clocktest). If you've constrained the CPU affinity >> outside fio, some of those will fail. In Windows, something like >> START /AFFINITY 0x55555555 fio ... >> can cause half of the clock threads to fail. > > This is very weird and doesn't make any sense (but I believe you): if > you have multiple threads crammed on to the same CPUs the TSC no > longer looks like it monotonically increases? Surely it should be MORE > likely to increase because a thread is likely to be on the same CPU as > another and can't actually be running at the same time as the other? The threads fail to start, it's not a TSC failure. I'm guessing it's because fio gets limited to a subset of the available CPUs, and that causes fio to fail doing the clock check when fio_setaffinity() in clock_thread_fn() fails. -- Jens Axboe