on
higher frequencies then main RAM and IMHO it must affect stability. For
video RAM some percent of errors is really less important, I have seen
it myself with my previous video card until it died completely.
--
Alexander Motin
___
freebsd-hackers
into uipaq driver alike
OpenBSD one. But I am not sure should this device be supported with
uipaq or umodem driver. umodem driver looks much more powerful, but I
have nothing to test it, as my WM6 does not provides USB modem support.
Could you try it also?
--
Alexander Motin
--- usbdevs.prev
it in machdep.c? Or I should
define it in machine dependent headers?
Also I would be grateful for help with implementations of this function
for arch different from i386/amd64.
Thanks.
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
small UMA zones with
preallocated queue to avoid part of UMA calls?
3) I have seen that UMA does some kind of CPU cache affinity, but does
it cost so much that it costs 30% CPU time on UP router?
Thanks!
--
Alexander Motin
___
freebsd-hackers
Alexander Motin пишет:
While profiling netgraph operation on UP HEAD router I have found that
huge amount of time it spent on memory allocation/deallocation:
I have forgotten to tell that it was mostly GENERIC kernel just built
without INVARIANTS, WITNESS and SMP but with 'profile 2
Kris Kennaway пишет:
Alexander Motin wrote:
Alexander Motin пишет:
While profiling netgraph operation on UP HEAD router I have found
that huge amount of time it spent on memory allocation/deallocation:
I have forgotten to tell that it was mostly GENERIC kernel just built
without INVARIANTS
Julian Elischer пишет:
Alexander Motin wrote:
Hi.
While profiling netgraph operation on UP HEAD router I have found that
huge amount of time it spent on memory allocation/deallocation:
0.14 0.05 132119/545292 ip_forward cycle 1 [12]
0.14 0.05 133127/545292
time profiling?
Thanks for reply.
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
have commented out all INVARIANTS and WITNESS options from GENERIC
kernel config. What else should I check?
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any
operations and brakes statistics. Is there any way to make it more
precise? What sampling parameters should I use for better results?
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
Peter Jeremy пишет:
On Sat, Feb 02, 2008 at 11:31:31AM +0200, Alexander Motin wrote:
To check UMA dependency I have made a trivial one-element cache which in my
test case allows to avoid two for four allocations per packet.
You should be able to implement this lockless using atomic(9). I
allocation order it does not fits CPU caches and
another that it is somehow related to critical_exit(), which possibly
can cause context switch. Does anybody have better explanation how such
small and simple in this part function can cause such results?
--
Alexander Motin
chances to be still present in cache.
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
then about objects caching.
I have got one more crazy idea that memory containing zones may have
some special hardware or configuration features, like noncaching or
something alike. That could explain slowdown in accessing it. But as I
can't prove it, it just one more crazy theory. :(
--
Alexander
: agp0: Intel 82865G (865G GMCH) SVGA
controller on vgapci0
Mar 3 23:01:20 swamp kernel: agp0: detected 892k stolen memory
Mar 3 23:01:20 swamp kernel: agp0: aperture size is 128M
, can they be related?
--
Alexander Motin
___
freebsd-hackers@freebsd.org
protected from being used after free?
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
.
URL: http://people.freebsd.org/~mav/netgraph.threads.patch
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
nodes).
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
queueing, node becomes an independent data source
which can be pinned to and processed by whatever specialized thread or
netisr, when it will be able to do it more effectively.
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http
will be spin-up in just a few seconds after
spin-down.
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
is not
implemented properly now and so blocked.
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Andriy Gapon wrote:
on 30/03/2009 14:14 Alexander Motin said the following:
Andriy Gapon wrote:
Recently I tried to hot-attach a SATA drive to a running system.
Controller is ICH9 in AHCI mode. Physically/electronically everything went
smoothly, the drive spun-up. Then I tried to detach
Alexander Motin wrote:
Danny Braniss wrote:
wups, forgot a small little detail:
ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-2.2.3.tar.gz
Is there reason why
cpi-transport = XPORT_ISCSI;
covered by
#if defined(KNOB_VALID_ADDRESS)
?
Sorry, wrong question. But those who will test
Hi.
Danny Braniss wrote:
wups, forgot a small little detail:
ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-2.2.3.tar.gz
Is there reason why
cpi-transport = XPORT_ISCSI;
covered by
#if defined(KNOB_VALID_ADDRESS)
?
--
Alexander Motin
about:
camcontrol devlist -v
camcontrol reset X
camcontrol rescan X
camcontrol devlist -v
, where X is mfip0 scbus number?
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
It is already fixed. Update your sources again.
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
0:00.07 dd
if=/dev/ada2 of=/dev/null bs=1m
So, does anybody have good idea why destroy_dev() can't complete?
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send
Kostik Belousov wrote:
On Sat, Jan 30, 2010 at 12:58:26AM +0200, Alexander Motin wrote:
Hi.
Experimenting with SATA hot-plug I've found quite repeatable deadlock
case. Problem observed when several SATA devices, opened via devfs,
disappear at exactly same time. In my case, at time
Pawel Jakub Dawidek wrote:
On Sat, Jan 30, 2010 at 12:27:49PM +0100, Pawel Jakub Dawidek wrote:
On Sat, Jan 30, 2010 at 12:58:26AM +0200, Alexander Motin wrote:
Experimenting with SATA hot-plug I've found quite repeatable deadlock
case. Problem observed when several SATA devices, opened via
to be a race with new I/O requests and
ioctl's, that are not protected by topology lock. At least if devfs code
doesn't handle it somehow.
--
Alexander Motin
--- geom_dev.c.prev 2010-01-30 05:22:36.0 +0200
+++ geom_dev.c 2010-02-01 11:55:53.0 +0200
@@ -184,10 +184,13 @@ g_dev_close
of
interrupts per core. For example, by setting:
kern.hz=100
hint.apic.0.clock=0
hint.atrtc.0.clock=0
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail
After reboot, i see in dmesg:
cd0 at ahcich4 bus 0 target 0 lun 0
cd0: TSSTcorp CDDVDW SH-S223B SB02 Removable CD-ROM SCSI-0 device
cd0: 150.000MB/s transfers
That way is also working.
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing
of the ahci(4) work, let's see what
he has to say and if he wants you to file a PR...
I forgot to say if that was on 8.0 release you should try again
with stable/8 first, maybe the bug is already fixed there.
Definitely. Many things were changed/fixed there.
--
Alexander Motin
of ICH7 chipsets (especially on cheap boards) do not support AHCI
mode. Only ICH7R and ICH7M do, if BIOS is so kind to enable it.
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
uses own lock, not Giant.
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
even better effect achieved by further reducing interrupt
rates on idle CPUs.
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers
Norikatsu Shigemura wrote:
On Sat, 24 Jul 2010 16:53:10 +0300
Alexander Motin m...@freebsd.org wrote:
PS: In this case benefit is small, but it is the least that can be
achieved, depending on CPU model. Some models allow frequency to be
risen by up to 6 steps (+798MHz).
I tested
Rui Paulo wrote:
On 24 Jul 2010, at 14:53, Alexander Motin wrote:
Here is my test case: FreeBSD 9-CURRENT on Core i5 650 CPU, 3.2GHz + 1/2
TurboBoost steps (+133/+266MHz) with boxed cooler at the open air. I was
measuring building time of the net/mpd5 from sources, using only one CPU
core
Robert Watson wrote:
On Sun, 25 Jul 2010, Alexander Motin wrote:
The numbers that you are showing doesn't show much difference. Have
you tried buildworld?
If you mean relative difference -- as I have told, it's mostly because
of my CPU. It's maximal boost is 266MHz (8.3%), but 133MHz of them
Alan Cox wrote:
On Mon, Jul 26, 2010 at 9:11 AM, Alexander Motin m...@freebsd.org
mailto:m...@freebsd.org wrote:
In that case using C2 or C3 predictably caused small performance reduce,
as after falling to sleep, CPU needs time to wakeup. Even if tested CPU0
won't ever sleep
latest patch against 9-CURRENT can be found here:
http://people.freebsd.org/~mav/timers_oneshot4.patch
Comments, ideas, propositions -- welcome!
Thanks to all who read this. ;)
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http
.clock=0
hint.attimer.0.clock=0
hint.hpet.0.legacy_route=1
It will disable RTC and i8254 timers, but grant their interrupts to
HPET, allowing it to work as per-CPU for dual-CPU systems.
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http
.
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Gary Jennejohn wrote:
On Mon, 30 Aug 2010 13:07:38 +0300
Alexander Motin m...@freebsd.org wrote:
Gary Jennejohn wrote:
Ah, I think I see it now. My desktop has only C1 enabled. Is that it?
Unfortunately, it appears that only C1 is supported :(
Yes, as I have said, at this moment empty
YAMAMOTO, Taku wrote:
On Mon, 30 Aug 2010 13:07:38 +0300
Alexander Motin m...@freebsd.org wrote:
Gary Jennejohn wrote:
(snip)
So, what else did you do to reduce interrupts so much?
Ah, I think I see it now. My desktop has only C1 enabled. Is that it?
Unfortunately, it appears that only
Alexander Motin wrote:
YAMAMOTO, Taku wrote:
On Mon, 30 Aug 2010 13:07:38 +0300
Alexander Motin m...@freebsd.org wrote:
Gary Jennejohn wrote:
(snip)
So, what else did you do to reduce interrupts so much?
Ah, I think I see it now. My desktop has only C1 enabled. Is that it?
Unfortunately
Gary Jennejohn wrote:
On Mon, 30 Aug 2010 12:11:48 +0200
Gary Jennejohn gljennj...@googlemail.com wrote:
On Mon, 30 Aug 2010 13:07:38 +0300
Alexander Motin m...@freebsd.org wrote:
Gary Jennejohn wrote:
Hmm. I applied your patches and am now running the new kernel. But I
only installed
Gary Jennejohn wrote:
On Mon, 30 Aug 2010 13:07:38 +0300
Alexander Motin m...@freebsd.org wrote:
Yes, as I have said, at this moment empty ticks skipped only while CPU
is in C2/C3 states. In C1 state there is no way to handle lost events on
wake up. While it may be not very dangerous
Alexander Motin wrote:
Gary Jennejohn wrote:
On Mon, 30 Aug 2010 12:11:48 +0200
OK, this is purely anecdotal, but I'll report it anyway.
I was running pretty much all day with the patched kernel and things
seemed to be working quite well.
Then, after about 7 hours, everything just stopped
Gary Jennejohn wrote:
On Wed, 01 Sep 2010 13:44:26 +0300
Alexander Motin m...@freebsd.org wrote:
I have reproduced the problem locally. It happens more often when ticks
are not stopped on idle, like in your original case (or if explicitly
enabled by kern.eventtimer.idletick sysctl).
I've
Alexander Leidinger wrote:
Quoting Alexander Motin m...@freebsd.org (from Sun, 29 Aug 2010
16:10:00 +0300):
I have actively tested this code for a few days on my amd64 Core2Duo
laptop and i386 Core-i5 desktop system. With C2/C3 states enabled
systems experience only about 100-150 interrupts
Gary Jennejohn wrote:
On Wed, 1 Sep 2010 14:15:41 +0200
Gary Jennejohn gljennj...@googlemail.com wrote:
On Wed, 01 Sep 2010 13:44:26 +0300
Alexander Motin m...@freebsd.org wrote:
Updated patch: http://people.freebsd.org/~mav/timers_oneshot6.patch
Patch also includes some optimizations
vmstat
-1`, I saw the interrupt rate on each HPET entry was over 120k!
Can I provide any useful detail? Of course, test patches are always welcome :)
I was able to reproduce alike storm in some situations.
Try new version: http://people.freebsd.org/~mav/timers_oneshot7.patch
--
Alexander Motin
. It could help if you
send me full log of those messages to create full picture.
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr
or duplicate drivers), required by it.
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
driver, as proposed (then it have to be duplicated in da and ada drivers
and possibly some others), or at the transport level, as present,
independent from drivers? I am not sure, but have feeling that tape
drives (for example) may also benefit from head parking before powering
down.
--
Alexander
Bruce Cran wrote:
On Sun, 24 Oct 2010 19:47:57 +0300
Alexander Motin m...@freebsd.org wrote:
Comparing two ways implementing spindown, I've recalled that both of
them using xpt_polled_action() method, which depends on working
controller polling operation. So they could be almost equaly
Tijl Coosemans wrote:
On Sunday 24 October 2010 18:47:57 Alexander Motin wrote:
I am not sure, but have feeling that tape drives (for example) may
also benefit from head parking before powering down.
USB hard disks would benefit as well I think. Although, ideally it
should happen after
on hardware. And it's reasonability also
depends on situation.
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr
. If bounce is also not working for you - it
definitely should be the first thing to fix.
From the other side ATM I see no good approach to this, as soon as CAM
devices are not present on NewBus to handle suspend events. Unless SIM
drivers will expose those events to CAM in some way.
--
Alexander
Alexander Best wrote:
On Wed Nov 17 10, Alexander Motin wrote:
Alexander Best wrote:
On Tue Nov 16 10, Bruce Cran wrote:
On Fri, 22 Oct 2010 10:03:09 +
Alexander Best arun...@freebsd.org wrote:
so how about olivers patch? it will only apply to ata devices so it's
garanteed not to break
.
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
properly.
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
(device_get_name(dev),
device_get_unit(dev), pm_level,ch-pm_level);
I did mention it on freebsd-current@ some time back:
http://lists.freebsd.org/pipermail/freebsd-current/2009-November/013645.html
Fixed at r215725. Thanks.
--
Alexander Motin
by DFLTPHYS - 64K.
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Andriy Gapon wrote:
on 10/12/2010 16:45 Alexander Motin said the following:
by default. Many SCSI drivers still limited by DFLTPHYS - 64K.
Including the cases where MAXBSIZE is abused because it historically has the
same
value.
DFLTPHYS automatically assumed by CAM for all SIMs
. Moreover, the chipset
supports different setting in primary master and primary slave.
There are few other controllers not supporting such configurations, but
it is handled by their specific drivers.
--
Alexander Motin
___
freebsd-hackers@freebsd.org
for the particular
board used to boot FreeBSD, what would you suggest to fix it?
Try latest FreeBSD -- 8.2 is now in RC state.
Try to disconnect devices one by one.
Try to limit initial mode via loader tunables (note that some of them
were added not so long ago and may be missing on 8.0).
--
Alexander Motin
-Dv?
You can use `set ...` command at the same loader command line before
typing `boot ...`. To make it permanent - you can add wanted options to
/boot/loader.conf file.
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http
Alexander Motin wrote:
Warner Losh wrote:
I don't suppose that your driver could cause the hardware to interrupt after
a little time? That would be more resource friendly... Otherwise, 1ms is
long enough that a msleep or tsleep would likely work quite nicely.
It's not his driver, it's
. I'll think about it.
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Alexander Motin wrote:
Warner Losh wrote:
I don't suppose that your driver could cause the hardware to interrupt after
a little time? That would be more resource friendly... Otherwise, 1ms is
long enough that a msleep or tsleep would likely work quite nicely.
It's not his driver, it's
for anything?
Even with old ATA names didn't match on my laptop: boot2 reports ad0,
while system - ad4. Also we have a lot of drivers who's disk names don't
fit into this set of ad, da and fd.
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
be impossible. It is up to each controller's BIOS to
report device or not. And some controllers may just have no/disabled
BIOS to report anything. Artificial separation between ad and da in
boot2 also doesn't makes thinks easier.
--
Alexander Motin
callout_* functions but I can't get through
them. Is there anyone who can help me?
Have you read callout(9) manual page? That API is right if you need to
call some function. Also in some cases (if you need to make your kernel
thread wait for something) you may use sleep(9) API.
--
Alexander Motin
recently.
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
argument types in ciss -- it is almost
null change, but may break some patches applicability. While using
uint32_t in CAM structures could be a benefit from compatibility point,
it is not important from this point in function arguments.
--
Alexander Motin
depends on both timecounter and eventtimer.
Also, please check whether kern.timecounter.tc.X.counter value changes for
the selected timercounter and whether you are receiving timer interrupts in
`vmstat -i`
--
Alexander Motin
___
freebsd-hackers
in `vmstat -i`
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
),
t-next);
}
- if (fdiv 5000) {
+ if (1 || fdiv 5000) {
bus_read_4(sc-mem_res, HPET_TIMER_COMPARATOR(t-num));
now = bus_read_4(sc-mem_res, HPET_MAIN_COUNTER);
--
Alexander Motin
___
freebsd-hackers
),
t-next);
}
- if (fdiv 5000) {
+ if (1 || fdiv 5000) {
bus_read_4(sc-mem_res, HPET_TIMER_COMPARATOR(t-num));
now = bus_read_4(sc-mem_res, HPET_MAIN_COUNTER);
--
Alexander Motin
Will do next.
Patch applied. Running
it tomorrow.
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Andriy Gapon wrote:
on 20/09/2011 23:04 Alexander Motin said the following:
On 20.09.2011 22:19, Andriy Gapon wrote:
just want to check with you first if the following makes sense.
I use SW_WATCHDOG on one of the test machines, which was recently updated to
from stable/8 to head. Now
this solution, as
it very low-level (ok, not so low-level as unsigned long long, to
be honest).
GEOM uses 64bit off_t for media size and many other things.
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman
error codes. :)
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Adrian Chadd wrote:
On 1 October 2011 17:25, Alexander Motin m...@freebsd.org wrote:
Use of critical section in cpu_idle() from the beginning was based on
number of assumptions about filter interrupt handler's limitations.
[snip]
So, if you really need to use callout() in interrupt
on your needs I am not sure it will
satisfy you.
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
() function now to all, but if we speaking about
general (perfect) case, we should either continue avoid this, or deny
things like what sparc64 does.
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd
, it is normal. You are not sick.
M: But that's not accurately enough! (ne akkuratnenko kak-to in
original transliteration)
http://blog.i.ua/user/2864472/779569/
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman
AND ada0 family devices.
That is compatibility shims. You can disable them if you want by adding
to /boot/loader.conf line: kern.cam.ada.legacy_aliases=0
--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman
4.9393758
Difference at 95.0% confidence
-51.1467 ± 20.6211
-3.66694% ± 1.47842%
(Student's t, pooled s = 9.09782)
Who wants to do independent testing to verify my results or do some more
interesting benchmarks? :)
PS: Sponsored by iXsystems, Inc.
--
Alexander Motin
On 02/06/12 18:01, Alexander Best wrote:
On Mon Feb 6 12, Alexander Motin wrote:
I've analyzed scheduler behavior and think found the problem with HTT.
SCHED_ULE knows about HTT and when doing load balancing once a second,
it does right things. Unluckily, if some other thread gets in the way
On 02/06/12 19:37, Tijl Coosemans wrote:
On Monday 06 February 2012 17:29:14 Alexander Motin wrote:
On 02/06/12 18:01, Alexander Best wrote:
On Mon Feb 6 12, Alexander Motin wrote:
I've analyzed scheduler behavior and think found the problem with HTT.
SCHED_ULE knows about HTT and when doing
On 02/06/12 21:08, Florian Smeets wrote:
On 06.02.12 08:59, David Xu wrote:
On 2012/2/6 15:44, Alexander Motin wrote:
On 06.02.2012 09:40, David Xu wrote:
On 2012/2/6 15:04, Alexander Motin wrote:
Hi.
I've analyzed scheduler behavior and think found the problem with HTT.
SCHED_ULE knows
On 02/11/12 15:35, Andriy Gapon wrote:
on 06/02/2012 09:04 Alexander Motin said the following:
I've analyzed scheduler behavior and think found the problem with HTT. SCHED_ULE
knows about HTT and when doing load balancing once a second, it does right
things. Unluckily, if some other thread gets
On 02/11/12 16:21, Alexander Motin wrote:
I've heavily rewritten the patch already. So at least some of the ideas
are already addressed. :) At this moment I am mostly satisfied with
results and after final tests today I'll probably publish new version.
It took more time, but finally I think
On 02/13/12 22:23, Jeff Roberson wrote:
On Mon, 13 Feb 2012, Alexander Motin wrote:
On 02/11/12 16:21, Alexander Motin wrote:
I've heavily rewritten the patch already. So at least some of the ideas
are already addressed. :) At this moment I am mostly satisfied with
results and after final
On 13.02.2012 23:39, Jeff Roberson wrote:
On Mon, 13 Feb 2012, Alexander Motin wrote:
On 02/13/12 22:23, Jeff Roberson wrote:
On Mon, 13 Feb 2012, Alexander Motin wrote:
On 02/11/12 16:21, Alexander Motin wrote:
I've heavily rewritten the patch already. So at least some of the
ideas
On 02/14/12 00:38, Alexander Motin wrote:
I see no much point in committing them sequentially, as they are quite
orthogonal. I need to make one decision. I am going on small vacation
next week. It will give time for thoughts to settle. May be I indeed
just clean previous patch a bit and commit
On 02/15/12 21:54, Jeff Roberson wrote:
On Wed, 15 Feb 2012, Alexander Motin wrote:
As before I've tested this on Core i7-870 with 4 physical and 8
logical cores and Atom D525 with 2 physical and 4 logical cores. On
Core i7 I've got speedup up to 10-15% in super-smack MySQL and
PostgreSQL
1 - 100 of 152 matches
Mail list logo
