In message <516c71bc.4000...@freebsd.org>, Alexander Motin writes:
>On 15.04.2013 23:43, Poul-Henning Kamp wrote:
>> In message <516c515a.9090...@freebsd.org>, Alexander Motin writes:
>>
>> For tuning anything on a non-ridiculous SSD device or modern
>> harddisks, it will be useless because of the
On 15.04.2013 23:43, Poul-Henning Kamp wrote:
In message <516c515a.9090...@freebsd.org>, Alexander Motin writes:
I propose to switch that
statistics from using binuptime() to getbinuptime() to solve the problem
globally.
No objections here, but I wonder if you were able to compare the result
In message <516c515a.9090...@freebsd.org>, Alexander Motin writes:
>>> I propose to switch that
>>> statistics from using binuptime() to getbinuptime() to solve the problem
>>> globally.
>> No objections here, but I wonder if you were able to compare the results
>> somehow before and after the ch
On Mon, Apr 15, 2013 at 09:37:30PM +0200, Pawel Jakub Dawidek wrote:
> On Mon, Apr 15, 2013 at 10:18:15PM +0300, Konstantin Belousov wrote:
> > On Mon, Apr 15, 2013 at 08:42:03PM +0200, Pawel Jakub Dawidek wrote:
> > > On a mostly unrelated note when two threads (T0 and T1) call get*time()
> > > on
On Mon, Apr 15, 2013 at 10:18:15PM +0300, Konstantin Belousov wrote:
> On Mon, Apr 15, 2013 at 08:42:03PM +0200, Pawel Jakub Dawidek wrote:
> > On a mostly unrelated note when two threads (T0 and T1) call get*time()
> > on two different cores, but T0 does that a bit earlier is it possible
> > that
On Mon, Apr 15, 2013 at 08:42:03PM +0200, Pawel Jakub Dawidek wrote:
> On a mostly unrelated note when two threads (T0 and T1) call get*time()
> on two different cores, but T0 does that a bit earlier is it possible
> that T0 can get later time than T1?
Define earlier first.
If you have taken suff
On 15.04.2013 21:42, Pawel Jakub Dawidek wrote:
On Sat, Apr 13, 2013 at 12:59:49PM +0300, Alexander Motin wrote:
Hi.
It is long known that collecting disk and GEOM statistics may cause
significant processing overhead under high IOPS. On my recent high-IOPS
benchmarks performance difference was
On Sat, Apr 13, 2013 at 12:59:49PM +0300, Alexander Motin wrote:
> Hi.
>
> It is long known that collecting disk and GEOM statistics may cause
> significant processing overhead under high IOPS. On my recent high-IOPS
> benchmarks performance difference was reaching three times! Last time
> situ
Hi.
It is long known that collecting disk and GEOM statistics may cause
significant processing overhead under high IOPS. On my recent high-IOPS
benchmarks performance difference was reaching three times! Last time
situation improved a lot by more active use of TSC, but there are still
many sy
9 matches
Mail list logo
