On Wed, 01.09.2010 at 16:23:43 -0700, Xin LI wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 2010/09/01 16:03, Alexander Best wrote:
> > hi there,
> >
> > there was a thread some time ago related to porting cputick2usec() to
> > userland [1].
> >
> > however it seems the idea g
From: Dag-Erling Smørgrav:
>
>Ilya Bakulin writes:
>> May you suggest any other tests?
>
>What other tests? The disks suck, how are more tests going to improve
>the situation?
>
>> Or let's live with sucking WD Green and look for other 4096K-sector
>> models from other manufacturers?
>
>I see no
On Wed, Sep 1, 2010 at 2:16 PM, Alexander Motin wrote:
> Brandon Gooch wrote:
>> This latest patch causes an interrupt storm with the HPET timer on my
>> system. The machine took about 8 minutes to boot and bring me to a
>> login prompt. System interactivity (i.e. input from keyboard, output
>> on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2010/09/01 16:03, Alexander Best wrote:
> hi there,
>
> there was a thread some time ago related to porting cputick2usec() to
> userland [1].
>
> however it seems the idea got lost at some point. i remember uqs working on an
> implementation, bu
hi there,
there was a thread some time ago related to porting cputick2usec() to
userland [1].
however it seems the idea got lost at some point. i remember uqs working on an
implementation, but can't remember the details.
a few people including uqs and jhb liked the idea. any comments on that?
c
On Wed Sep 1 10, Dag-Erling Smørgrav wrote:
> Alexander Best writes:
> > just having a quick look around to see, if anybody would be interested in
> > fetch -B and fetch -S accepting humanized numbers using expand_number()?
>
> I can understand it for -B, but not for -S, since in the common case
2010/9/1 Dag-Erling Smørgrav :
> Consider the following commit:
>
> r89471 | joerg | 2002-01-17 21:26:14 +0100 (Thu, 17 Jan 2002) | 8 lines
>
> Provide an option to make camcontrol `minimalistic': if the (env/make)
> variable RELEASE_BUILD_FIXIT is defined, a camcontrol binary will be
> built t
Brandon Gooch wrote:
> This latest patch causes an interrupt storm with the HPET timer on my
> system. The machine took about 8 minutes to boot and bring me to a
> login prompt. System interactivity (i.e. input from keyboard, output
> on console) was fine, but after checking the output of `systat v
Consider the following commit:
r89471 | joerg | 2002-01-17 21:26:14 +0100 (Thu, 17 Jan 2002) | 8 lines
Provide an option to make camcontrol `minimalistic': if the (env/make)
variable RELEASE_BUILD_FIXIT is defined, a camcontrol binary will be
built that only knows the "rescan" and "reset" sub
Alexander Best writes:
> just having a quick look around to see, if anybody would be interested in
> fetch -B and fetch -S accepting humanized numbers using expand_number()?
I can understand it for -B, but not for -S, since in the common case (by
1023 to 1, assuming a random distribution) the arg
On Wed, Sep 1, 2010 at 5:44 AM, Alexander Motin wrote:
> 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
Gary Jennejohn wrote:
> On Wed, 1 Sep 2010 14:15:41 +0200
> Gary Jennejohn wrote:
>
>> On Wed, 01 Sep 2010 13:44:26 +0300
>> Alexander Motin wrote:
>>> Updated patch: http://people.freebsd.org/~mav/timers_oneshot6.patch
>>>
>>> Patch also includes some optimizations to reduce lock contention.
>>
On Wed, 1 Sep 2010 14:15:41 +0200
Gary Jennejohn wrote:
> On Wed, 01 Sep 2010 13:44:26 +0300
> Alexander Motin wrote:
> > Updated patch: http://people.freebsd.org/~mav/timers_oneshot6.patch
> >
> > Patch also includes some optimizations to reduce lock contention.
> >
> > Thanks for testing.
>
Quoting Alexander Motin (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 per second, having HZ
set to 1000. These even
Alexander Leidinger wrote:
> Quoting Alexander Motin (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 per sec
Gary Jennejohn wrote:
> On Wed, 01 Sep 2010 13:44:26 +0300
> Alexander Motin 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 made so
On Wed, 01 Sep 2010 13:44:26 +0300
Alexander Motin wrote:
> 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
> >> se
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
On Wed, 01 Sep 2010 00:27:36 +0300
Alexander Motin wrote:
> Gary Jennejohn wrote:
> > On Mon, 30 Aug 2010 13:07:38 +0300
> > Alexander Motin 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 even
On 09/01/10 08:16, Michael Bushkov wrote:
If you don't mind, as I've worked extensively with nsswitch, I can
check the current implementation and provide you a patch to update the
docs.
Of course, go ahead.
___
freebsd-hackers@freebsd.org mailing li
20 matches
Mail list logo
