Hi,
I wondered about this. However, after looking around what
I found was that the FIO* requests seemed to be documented
in driver pages (and only a handful at that), and not
documented with ioctl.
Since I don't want to change the other existing driver
man pages, what if I add generic
Matt Dillon wrote:
It is not implying that at all. There is no black and white here.
This is a case where spending a huge amount of time and complexity
to get the efficiency down to the Nth degree is nothing but a waste
of time. What matters is what the user sees, what
* Doug Barton [EMAIL PROTECTED] [010417 01:08] wrote:
Matt Dillon wrote:
It is not implying that at all. There is no black and white here.
This is a case where spending a huge amount of time and complexity
to get the efficiency down to the Nth degree is nothing but a waste
* Matt Dillon [EMAIL PROTECTED] [010415 23:16] wrote:
For example, all this work on a preemptive
kernel is just insane. Our entire kernel is built on the concept of
not being preemptable except by interrupts. We virtually guarentee
years of
Alfred Perlstein wrote:
I'm figuring the only time when it may be a problem is on machines
with a small amount of memory. Since memory is cheap, I plan on
turning it on within the next couple of days unless a stability
issue comes up.
I'll leave it to those people with low memory to
subscribe freebsd-current
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
OK... this brings up the question of what other cool optimizations are
there that may have been disabled in the past for reasons that are no
longer pertinent? It might be worthwhile to create an /etc/sysctl.conf file
with commented out examples of configurations for various systems. For
Sorry for replying this topic, a little bit OT this time :-)
On Thu, Apr 12, 2001 at 09:20:34AM -0700, Lars Eggert wrote:
Michael Johnson wrote:
Theres not a iso for -CURRENT .. It changes too much.
Too bad.
you can make your own iso though. ports/sysutils/mkisofs
Yes, I've done
Hi!
It is my great pleasure to announce the availability of just released
Groff 1.17. Please refer to the src/contrib/groff/NEWS for details on
what's new in this release.
This release includes the complete re-implementation of the BSD mdoc(7)
macro package, earlier referred to as -mdocNG.
On Tue, Apr 17, 2001 at 16:33:18 +0300, Ruslan Ermilov wrote:
FreeBSD-specific -mdoc configuration file is called mdoc.local. This
version also provides a simple way to localize -mdoc. For now, only
KOI8-R support is implemented. See gnu/usr.bin/groff/tmac/koi8-r for
details.
Is this
On Tue, 17 Apr 2001, Ruslan Ermilov wrote:
It is my great pleasure to announce the availability of just released
Groff 1.17. Please refer to the src/contrib/groff/NEWS for details on
what's new in this release.
This is great news -- especially the argument limit removal :-). Thanks
for
On 17-Apr-01 Jesper Skriver wrote:
On Mon, Apr 16, 2001 at 08:10:37PM -0700, John Baldwin wrote:
On 15-Apr-01 Jesper Skriver wrote:
About every other time I boot my IBM ThinkPad 600E I get this panic
(hand typed, as I don't have a second machine here to be able to use a
serial
I'm running 5.0-Current-4.12.2001, X-Kern-Developer with all binaries,
have just installed the samba package (pkg_add -r samba) but the smb
client services, specifically mount_smbfs, aren't installed.
I cannot find reference anywhere to which package the mount_smbfs binary
belongs to. Can
Date: Tue, 17 Apr 2001 12:34:39 -0700 (PDT)
From: John Baldwin [EMAIL PROTECTED]
=== usr.sbin/pcvt/vttest
cc -O -pipe -traditional -DUSEMYSTTY -I/usr/obj/usr/src/i386/usr/include -c
/usr/src/usr.sbin/pcvt/vttest/main.c
cc -O -pipe -traditional -DUSEMYSTTY
Oops.
NOTE: I don't follow this lists for weeks at a time, so please
include me directly in any responses. Thanks.
Matt Dillon was looking at this, but I haven't heard from him
for a while on it.
Here is a patch to make it panic, instead of really, really
trashing memory (ignore the version,
:
:There's actually very little code that non-premptable once we get the
:kernel mutexed. The least complex way to accomplish this is to only
:preempt kernel processes that hold no mutex (low level) locks.
:
:--
:-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
I wish it were that
You need to settle dude, pre-emption isn't a goal, it's mearly a
_possible_ side effect.
We're not aiming for pre-emption, we're aiming for more concurrancy.
* Matt Dillon [EMAIL PROTECTED] [010417 13:51] wrote:
:
:There's actually very little code that non-premptable once we get the
:
:You need to settle dude, pre-emption isn't a goal, it's mearly a
:_possible_ side effect.
:
:We're not aiming for pre-emption, we're aiming for more concurrancy.
A goal of having more concurrency is laudable, but I think you are
ignoring the costs of doing task switches verses the
On Wed, 18 Apr 2001 06:40:38 +1000 (EST), Bruce Evans [EMAIL PROTECTED] said:
Does POSIX now specify select() and/or poll() precisely enough to
show that the current behaviour is wrong?
In addition to more explicit requirements for sockets, draft 6 has the
following to say about select() and
On Tue, 17 Apr 2001, Matt Dillon wrote:
:You need to settle dude, pre-emption isn't a goal, it's mearly a
:_possible_ side effect.
:
:We're not aiming for pre-emption, we're aiming for more concurrancy.
A goal of having more concurrency is laudable, but I think you are
ignoring
* Matt Dillon [EMAIL PROTECTED] [010417 14:07] wrote:
:
:You need to settle dude, pre-emption isn't a goal, it's mearly a
:_possible_ side effect.
:
:We're not aiming for pre-emption, we're aiming for more concurrancy.
A goal of having more concurrency is laudable, but I think you
:Oops.
:
:NOTE: I don't follow this lists for weeks at a time, so please
:include me directly in any responses. Thanks.
:
:Matt Dillon was looking at this, but I haven't heard from him
:for a while on it.
:
:Here is a patch to make it panic, instead of really, really
:trashing memory (ignore the
:Once the mutexes are in place the underlying implementation can
:change pretty easily from task switching always to only task
:switching when the mutex is owned by the same CPU that I'm running
:on. (to avoid spinlock deadlock)
That makes *NO* *SENSE* Alfred! So the first step is to
Thanks, the patch appears to work fine.
Sorry for the delay in testing it, long weekend here.
-Darren
On Fri, 13 Apr 2001, Andrew Gallatin wrote:
Darren Henderson writes:
I had a functional install of -current which was created back on Jan 11th of
this year.
I cvsup'd
Date: Tue, 17 Apr 2001 14:52:06 -0700
From: Alfred Perlstein [EMAIL PROTECTED]
Disclaimer: I am not a kernel hacker.
The goal is to have a kernel that's able to have more concurrancy,
Right...
things like pre-emption and task switching on mutex collisions can
be examined and possibly
* Matt Dillon [EMAIL PROTECTED] [010417 15:00] wrote:
:Once the mutexes are in place the underlying implementation can
:change pretty easily from task switching always to only task
:switching when the mutex is owned by the same CPU that I'm running
:on. (to avoid spinlock deadlock)
On Tue, 17 Apr 2001, David Wolfskill wrote:
Date: Tue, 17 Apr 2001 12:34:39 -0700 (PDT)
From: John Baldwin [EMAIL PROTECTED]
...
In file included from /usr/src/usr.sbin/pcvt/vttest/header.h:26,
from /usr/src/usr.sbin/pcvt/vttest/main.c:20:
Date: Tue, 17 Apr 2001 22:18:34 + (GMT)
From: E.B. Dreger [EMAIL PROTECTED]
My instinct (whatever it's worth; remember my disclaimer) is that co-op
switching using something like tsleep() and wakeup_one() or similar would
be more efficient than trying to screw with mutexes.
Oops. I
Does anyone know of a possible bug/panic with the swap partition? I tried
to view a file with vi/pico on -current (10+M file) and it crashed the machine.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Hello everybody,
first of all sorry if this is not the proper list for writing this. This is my first
posting and I'm new to FreeBSD, so please forgive me if I am sending crap in this
message.
I needed to install Netware filesystem support and noticed that if I want to mount
the nwfs via
NB: To keep me in the loop, keep me in the Cc: list, since I
rarely follow -current these days).
I've further localized the bug to the freeing of credentials
associated with socket buffers, and being unrelated to the
crhold()/crfree() calls in socreate() and sodealloc().
Specifically, the bug
On Tuesday, 17 April 2001 at 1:19:57 -0700, Alfred Perlstein wrote:
* Matt Dillon [EMAIL PROTECTED] [010415 23:16] wrote:
For example, all this work on a preemptive
kernel is just insane. Our entire kernel is built on the concept of
not being
* Greg Lehey [EMAIL PROTECTED] [010417 17:02] wrote:
On Tuesday, 17 April 2001 at 1:19:57 -0700, Alfred Perlstein wrote:
* Matt Dillon [EMAIL PROTECTED] [010415 23:16] wrote:
For example, all this work on a preemptive
kernel is just insane. Our entire
On Tue, Apr 17, 2001 at 05:47:23PM -0700, Matt Dillon wrote:
Proposed:
mainline kernel {
get_spin_mutex(somemutex);
.
.
masked interrupt occurs, interrupt structure contains array
of mutexes the interrupt will need. Check said
* Matt Dillon [EMAIL PROTECTED] [010417 17:47] wrote:
...
Interrupts by definition know precisely what they are going to do, so by
definition they know precisely which mutexes (if any) they may need
to get. This means that, in fact, it is possible to implement a check
to
:
: You cannot be pre-empted by an interrupt if you are holding a spin
: mutex, AFAIK, even under present implementation.
Since spin mutexes are going to be held all over the place, this
type of restriction would seem to be detrimental. If you can do all
the checking up-front
Date: Tue, 17 Apr 2001 21:20:45 -0400
From: Bosko Milekic [EMAIL PROTECTED]
What happens if we get an interrupt, we're thinking about servicing
it, about to check whether we're already holding a mutex that may
potentially be used inside the mainline int routine, and another CPU
becomes
* Terry Lambert [EMAIL PROTECTED] [010417 16:28] wrote:
I guess no one else is interested in this bug hunt, or no one else
is using 30,000 sockets on any of their machines?
I've committed a variation of your invariants check to -current,
-stable is frozen and I'd prefer to leave it as is
* E.B. Dreger [EMAIL PROTECTED] [010417 18:36] wrote:
In this case, why not have a memory allocator similar to Hoard?
It doesn't work, but it's close:
http://people.freebsd.org/~alfred/memcache/
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
Represent yourself, show up at
* E.B. Dreger [EMAIL PROTECTED] [010417 18:48] wrote:
Date: Tue, 17 Apr 2001 18:28:40 -0700
From: Alfred Perlstein [EMAIL PROTECTED]
1) interrupts are again fan-in, meaning if you block an interrupt
class on one cpu you block them on all cpus
When would this be a bad case?
: Mutex creation can be expensive as it seems like each interrupt
: needs to register what sort of mutex it's interested in, when a
: mutex is created the list must be scanned and each interrupt
: updated.
The list is based in the interrupt structure. The cost is, what,
four or
Date: Tue, 17 Apr 2001 19:06:08 -0700 (PDT)
From: Matt Dillon [EMAIL PROTECTED]
They don't have to be. If you have four NICs each one can be its own
interrupt, each with its own mutex. Thus all four can be taken in
parallel. I was under the impression that BSDI had achieved that
in
:IIRC, didn't the NT driver for some NIC (Intel?) switch to polling,
:anyway, under heavy load? The reasoning being that you _know_ that you're
:going to get something... why bother an IRQ hit?
:
:That said, IRQ distribution sounds like a good thing for the general case.
Under a full load
Date: Tue, 17 Apr 2001 19:34:56 -0700 (PDT)
From: Matt Dillon [EMAIL PROTECTED]
Yes. Also NICs usually have circular buffers for packets so, really,
only one cpu can be processing a particular NIC's packets at any given
moment.
We could always have a mutex for each NIC's ring buffer...
IIRC, didn't the NT driver for some NIC (Intel?) switch to polling,
anyway, under heavy load? The reasoning being that you _know_ that you're
going to get something... why bother an IRQ hit?
THis is very interesting. How does this affect performance?
JAn
To Unsubscribe: send mail to [EMAIL
Just an update...
] In any case, I'm leaving in the panic patch I sent earlier, and am
] now rebuilding with my ucred reference count moved past the area
Moving the reference count of of the range of the stop clears
up the invariant corruption complaint.
It is now abundantly clear that a
On Tue, 17 Apr 2001, Matt Dillon wrote:
Under a full load polling would work just as well as an interrupt.
With NT for the network tests they hardwired each NIC to a particular
CPU. I don't know if they did any polling or not.
Not true. Interrupts work worse than polling because
Date: Wed, 18 Apr 2001 00:04:12 -0300 (BRST)
From: Rik van Riel [EMAIL PROTECTED]
Not true. Interrupts work worse than polling because the interrupt
top halves can keep the CPU busy, whereas with polling you only
Top halves and _task switching_. Again, in a well-written handler with a
Going back to basic principles:
For minimal CPU utilization, it would be nice skip task switching, period.
Run something to completion, then go on to the next task. Poll without
ever using an interrupt.
The problem is that latency becomes totally unacceptable.
So now let's go to the other
usb.h != libusb.h
NetBSD has a stupid naming convention. Use libusb.h in FreeBSD.
Ok. That's as may be, but then why are there prototypes for libusb
calls in dev/usb.h?
Sorry, meant to say /usr/include/dev/usb/hid.h
The prototypes are correct as is.
They may be in libusb.h,
usb.h != libusb.h
NetBSD has a stupid naming convention. Use libusb.h in FreeBSD.
The prototypes are correct as is. The changes to libusb made in CURRENT
have not been backported to STABLE (yet).
Nick
On Tue, 17 Apr 2001, Nick Sayer wrote:
The definition of hid_report_size() differs
usb.h != libusb.h
NetBSD has a stupid naming convention. Use libusb.h in FreeBSD.
Ok. That's as may be, but then why are there prototypes for libusb calls in
dev/usb.h?
The prototypes are correct as is.
They may be in libusb.h, but the prototype for that function in
sys/dev/usb.h is
On Wed, 18 Apr 2001, User wrote:
mount -a -t nonfs
to
# Mount everything except nfs filesystems.
mount -a -t nonfs,nwfs
In the first case at boot time the machine stops and wants me to enter
in shell and fix the problem. I don't know whether I'm right, but I
think that my
On Tue, 17 Apr 2001 [EMAIL PROTECTED] wrote:
I'm running 5.0-Current-4.12.2001, X-Kern-Developer with all binaries,
have just installed the samba package (pkg_add -r samba) but the smb
client services, specifically mount_smbfs, aren't installed.
mount_smbfs doesn't belong to the
On Wed, 18 Apr 2001, E.B. Dreger wrote:
For minimal CPU utilization, it would be nice skip task switching,
period. Run something to completion, then go on to the next task.
Poll without ever using an interrupt.
[snip]
Hence, my philosophy is that task switching and preemption are
55 matches
Mail list logo
