Re: cvs commit: src/sys/fs/specfs spec_vnops.c
On Mon, Nov 04, 2002 at 09:49:06AM +0100, Stijn Hoop wrote: > On Mon, Nov 04, 2002 at 08:48:01AM +0100, Poul-Henning Kamp wrote: > > In message <[EMAIL PROTECTED]>, Doug Barton writes: > > >Kirk, > > > > > >I'm adding a bunch of people to the list who were involved in a thread > > >on -current on this topic. I also tried this change and noticed that > > >things did seem a tiny bit snappier (although my system is slow enough > > >that it could have just been my imagination). > > > > All things considered, I think we should just pla to leave it this way > > for 5.0-R. Until now people were used to wait for fsck to finish, at > > least now they can do something in while it runs. > > Well... like I indicated earlier in the thread on -CURRENT, things > were definitely *slow*. I also said I would try to provide benchmarks > if people told me how to do that (and what to time). In any case, > as a rough measurement, starting X on -CURRENT took about 2-3 seconds > vs. about half a second on -STABLE on the exact same hardware. > > It was even measurable on a simple 'ls' in a large directory. > > I think if this is left in as is, people 'new' to FreeBSD will think > it's dead slow, and move on elsewhere. Whoops, monday morning brain fart. Ignore my previous mail, I didn't get the fact that the switch defaulted to *off*. Am I reading it correctly now, that the ioslow sleep is therefore also not enabled by default? --Stijn -- The most reliable proof that there are extraterrestrial intelligent lifeforms out there is that nobody actually tries to get in contact with us. -- Dirk Mueller msg46045/pgp0.pgp Description: PGP signature
Re: cvs commit: src/sys/fs/specfs spec_vnops.c
On 04-Nov-2002 Doug Barton wrote: > Kirk, > > I'm adding a bunch of people to the list who were involved in a thread > on -current on this topic. I also tried this change and noticed that > things did seem a tiny bit snappier (although my system is slow enough > that it could have just been my imagination). > > Thanks, > > Doug On a similar note, I'm still trying to determine the impact of enabling/disabling CFLAGS+=-D_PTHREADS_INVARIANTS in libc_r and libpthreads, and wondering if perhaps a global -DNO_INVARIANTS variable in src/Makefile.inc1 might be something worth considering. It's hard to tell just how much of a difference this really makes. Has anyone done any comparisons on this? Do these have any effect at all if the kernel is built without INVARIANT_SUPPORT? > Kirk McKusick wrote: >> >> mckusick2002/11/03 23:29:20 PST >> >> Modified files: >> sys/fs/specfsspec_vnops.c >> Log: >> Add debug.doslowdown to enable/disable niced slowdown on I/O. Default >> to off until locking interference issues get sorted out. >> >> Sponsored by: DARPA & NAI Labs. >> >> Revision ChangesPath >> 1.186 +5 -1 src/sys/fs/specfs/spec_vnops.c >> >> http://www.FreeBSD.org/cgi/cvsweb.cgi/src/sys/fs/specfs/spec_vnops.c.diff >> ?&r1=1.185&r2=1.186&f=h > > -- >"We have known freedom's price. We have shown freedom's power. > And in this great conflict, ... we will see freedom's victory." > - George W. Bush, President of the United States > State of the Union, January 28, 2002 > > Do YOU Yahoo!? > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > -- Conrad Sabatier <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/fs/specfs spec_vnops.c
On Mon, Nov 04, 2002 at 08:48:01AM +0100, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Doug Barton writes: > >Kirk, > > > >I'm adding a bunch of people to the list who were involved in a thread > >on -current on this topic. I also tried this change and noticed that > >things did seem a tiny bit snappier (although my system is slow enough > >that it could have just been my imagination). > > All things considered, I think we should just pla to leave it this way > for 5.0-R. Until now people were used to wait for fsck to finish, at > least now they can do something in while it runs. Well... like I indicated earlier in the thread on -CURRENT, things were definitely *slow*. I also said I would try to provide benchmarks if people told me how to do that (and what to time). In any case, as a rough measurement, starting X on -CURRENT took about 2-3 seconds vs. about half a second on -STABLE on the exact same hardware. It was even measurable on a simple 'ls' in a large directory. I think if this is left in as is, people 'new' to FreeBSD will think it's dead slow, and move on elsewhere. > I belive GEOM provides the framework where we can properly tag I/O > requests with a priority, propagate that priority down to the device > drivers and act accordingly in the disksort disk-scheduling code. If that's the case, I'd like to see it in 5.0R. > That would allow us to address not only the bgfsck but also things > like silly-seek-syndrome and other sub-optimal issues in our current > I/O system. That would be great. --Stijn -- The right half of the brain controls the left half of the body. This means that only left handed people are in their right mind. msg46035/pgp0.pgp Description: PGP signature
Re: cvs commit: src/sys/fs/specfs spec_vnops.c
In message <[EMAIL PROTECTED]>, Doug Barton writes: >Kirk, > >I'm adding a bunch of people to the list who were involved in a thread >on -current on this topic. I also tried this change and noticed that >things did seem a tiny bit snappier (although my system is slow enough >that it could have just been my imagination). All things considered, I think we should just pla to leave it this way for 5.0-R. Until now people were used to wait for fsck to finish, at least now they can do something in while it runs. I belive GEOM provides the framework where we can properly tag I/O requests with a priority, propagate that priority down to the device drivers and act accordingly in the disksort disk-scheduling code. That would allow us to address not only the bgfsck but also things like silly-seek-syndrome and other sub-optimal issues in our current I/O system. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/fs/specfs spec_vnops.c
Kirk, I'm adding a bunch of people to the list who were involved in a thread on -current on this topic. I also tried this change and noticed that things did seem a tiny bit snappier (although my system is slow enough that it could have just been my imagination). Thanks, Doug Kirk McKusick wrote: > > mckusick2002/11/03 23:29:20 PST > > Modified files: > sys/fs/specfsspec_vnops.c > Log: > Add debug.doslowdown to enable/disable niced slowdown on I/O. Default > to off until locking interference issues get sorted out. > > Sponsored by: DARPA & NAI Labs. > > Revision ChangesPath > 1.186 +5 -1 src/sys/fs/specfs/spec_vnops.c > > >http://www.FreeBSD.org/cgi/cvsweb.cgi/src/sys/fs/specfs/spec_vnops.c.diff?&r1=1.185&r2=1.186&f=h -- "We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory." - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/fs/specfs spec_vnops.c
In message <[EMAIL PROTECTED]>, Poul-Henning Kamp
writes:
>phk 2002/11/01 07:32:12 PST
>
> Modified files:
>sys/fs/specfsspec_vnops.c
> Log:
> Put a KASSERT in specfs::strategy() to check that the incoming buffer
> has a valid b_iocmd. Valid is any one of BIO_{READ,WRITE,DELETE}.
>
> I have seen at least one case where the bio_cmd field was zero once the
> request made it into GEOM. Putting the KASSERT here allows us to spot
> the culprit in the backtrace.
If any of you encounter this panic ("Wrong b_iocmd buf...") please
try to capture a traceback and mail it to me.
This is likely connected to the problems Kirk are debugging right now
and may be responsible for some of the weirder Heisenbugs people have
reported.
Worst case, (before this commit) it could result in a read request
being carried out as a write request by a disk device driver.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
