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
> ne
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, 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
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 extr
> 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
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 becau
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 cre
> 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 [EMA
> 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 buff
: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 p
> 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
: 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 five
* 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 b
* 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
> 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? i.e., if an interrupt [class] must be
blocked, would we
* 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
> 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
> be
:
: 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
* 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
>
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. Ch
* 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 insan
On Tue, Apr 17, 2001 at 10:18:34PM +, E.B. Dreger 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
>
> I'm not sure that I follow.
:*sigh* Couldn't you have changed the subject line when discussing
:something of this importance?
:
:Greg
Sorry. Now I am so much in a huff I'm thinking about how all this
could be implemented from scratch with the 4.x base. I know, I know,
good luck Matt...
For example, this
(cross-posting to SMP and renaming in an effort to move the thread)
> Date: Tue, 17 Apr 2001 16:04:18 -0700
> From: Alfred Perlstein <[EMAIL PROTECTED]>
(Repeat disclaimer: I am not a kernel hacker.)
> seriously, it would be _trivial_ to:
>
> 1) make interrupts the only thing that could swit
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
:There seems to be some bad code in soo_close(), which looks like:
:
: int
: soo_close(fp, p)
: struct file *fp;
: struct proc *p;
: {
: int error = 0;
:
: fp->f_ops = &badfileops;
: if (fp->f_data)
:
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 ex
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 /
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
> 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.
Oop
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:
> >/usr/obj/usr/src/i38
* 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)
>
> Date: Tue, 17 Apr 2001 15:00:29 -0700 (PDT)
> From: Matt Dillon <[EMAIL PROTECTED]>
>
> WILL be a performance hit. WILL introduce major bugs. IS unnecessary,
> DOESN'T make any sense whatsoever, is at CROSS PURPOSES with goals
> already stated (not having any serious contention in the first p
> 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 possib
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.
> >
> >
: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 intro
: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
* 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 t
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
> ig
< 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 pselect():
A descriptor shall be considered ready for readin
:
: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 l
I committed this earlier..thanks.
Kris
PGP signature
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
> :k
:
: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
On Tue, 17 Apr 2001, Garrett Wollman wrote:
> < said:
>
> > ie: FIONREAD will succeed from a backgrounded process, but the
> > data read itself with hang (tty driver).
>
> You are describing a general property of the terminal subsystem, which
> any process dealing with terminals needs to be
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, I
>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 -I/usr/obj/usr/src/i
I mentioned a very bad bug on the -arch list a while back, which
occurred when
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
* Matt Dillon <[EMAIL PROTECTED]> [010417 10:22] 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
-FW: <[EMAIL PROTECTED]>-
Date: Tue, 17 Apr 2001 08:50:35 -0700 (PDT)
From: Deimos Root <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Snapshot Log
rm -f vt220l.816
uudecode /usr/src/usr.sbin/pcvt/fonts/vt220l.814.uu
uudecode /usr/src/usr.sbin/pcvt/fonts/vt220l.810.uu
uudecode /usr/
On Tue, Apr 17, 2001 at 02:31:38PM -0400, [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.
>
> I cannot find ref
>>
>> 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 b
>
> 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
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 anyo
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
>> > se
< said:
> ie: FIONREAD will succeed from a backgrounded process, but the
> data read itself with hang (tty driver).
You are describing a general property of the terminal subsystem, which
any process dealing with terminals needs to be aware of.
(AFAIK, ioctl(tty, FIONREAD, &n) should set n t
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 console).
> >
> > Fatal trap 12: page
:
: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 see
:* 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
:> ye
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 betw
I am planning to shift a machine from -current to the pending release.
I have tracked -current (SMP) on this machine for > 4 years. But,
now, I need to depend on it - it is old, making a net server.
What date were the etc/* files frozen for the pending release?
I plan to do a new install, just
[Redirected to -i18n]
On Tue, Apr 17, 2001 at 06:39:34PM +0400, Andrey A. Chernov wrote:
> On Tue, Apr 17, 2001 at 17:04:19 +0300, Ruslan Ermilov wrote:
[...]
>
> > difference in implementation (the current implementation simply redefines
> > some -mdoc string variables), if you run ``nroff -mdo
On Tue, Apr 17, 2001 at 17:04:19 +0300, Ruslan Ermilov wrote:
> >
> Why do you think it is gone?
I base yourself on commit logs and miss repo copy.
> difference in implementation (the current implementation simply redefines
> some -mdoc string variables), if you run ``nroff -mdoc'' for Englis
The definition of hid_report_size() differs between -stable and -current (as
to its prototype), yet /usr/src/sys/dev/usb.h shows no difference between
-stable and -current, and is wrong in either case.
This is causing some heartburn for -current builders of the xmame port.
To Unsubscribe: send
On Tue, Apr 17, 2001 at 05:37:54PM +0400, Andrey A. Chernov wrote:
> 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 suppor
On Tue, 17 Apr 2001 09:36:55 -0400, Robert Watson wrote:
> This is great news -- especially the argument limit removal :-).
Indeed!
If for nothing else, Ruslan's work will be much appreciated for the fact
that we no longer have to jump through .Xo / .Xc hoops to get around the
old argument li
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 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
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. The
On Mon, 16 Apr 2001, Garrett Wollman wrote:
> < said:
>
> >I've been doing some tty related work and found the FIO*
> > requests don't seem to be documented.
>
> >I've added some reasonable doc to tty.4 and put up the
> > the diff and html forms:
>
> As the initial letter suggests, the
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'v
> 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.
subscribe freebsd-current
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
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 t
* 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
* 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
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 p
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 docu
78 matches
Mail list logo
