Date: Sun, 14 Jun 1998 14:50:02 -0700 (PDT) From: Matthew Dillon <dillon@backplane.com> To: freebsd-bugs@FreeBSD.ORG Subject: Re: i386/6944: bug in i386/isa/icu_ipl.s - AST gets lost, causes extreme network slowdown when cpu-bound processes present, possibly other problems Message-ID: <199806142150.OAA12657@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR i386/6944; it has been noted by GNATS.
From: Matthew Dillon <dillon@backplane.com>
To: Bruce Evans <bde@zeta.org.au>
Cc: bde@zeta.org.au, FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: i386/6944: bug in i386/isa/icu_ipl.s - AST gets lost, causes extreme network slowdown when cpu-bound processes present, possibly other problems
Date: Sun, 14 Jun 1998 14:41:35 -0700 (PDT)
:> Well, I spent 6 hours from 9p.m. to 3a.m. just find this :-) I'm going
:> to leave the finding of the broken spl to someone else, but there ARE
:> several places where $0 is loaded into the cpl in the assembly, and
:
:Mainly SMP places in swtch.s and VM86 places in ipl.s. I can't see any
:relevant problems there (except it's hard to see anything because of the
:ifdefs).
Yah, I checked that out... but the problem was still there after turning
off VM86, and I've got SMP turned off. I also have APIC_IO turned off.
:> The problem is extremely reproducable... just NFS mount / and /usr from
:> a server to a workstation, run a for (;;); process on the server, and
:> try to run xterm on the workstation and, poof.
:
:Not reproducible here. I'll try using VM86.
Damn. I was hoping it would be easily reproduceable. I see the same
effect on our 2.2.x production machines.
The diskless workstation is a -current kernel talking to a -current
server. nfsd -n 4 on the server, nfsiod -n 2 on the client. In one
of my iterations I was dumping debugging printf()'s in the kernel,
which showed that while the forever process ./x was running, the nfs
socket wakeup WAS setting the AST in ipending along with want_resched,
but that nfsd wasn't getting woken up until the next timer tick. If
the machine was idle (no forever process), nfsd would get the cpu
immediately.
Also, another point of reference: If the forever process is running but
with system call in a tight loop, like this:
for (;;)
write(1, buf, 0);
Then the nfsd would get woken up instantly for each request. But if the
forever process was running like this:
for (;;)
;
The nfsd would not get woken up until the next timer tick.
-Matt
:
:Bruce
Matthew Dillon Engineering, BEST Internet Communications, Inc.
<dillon@backplane.com>
[always include a portion of the original email in any response!]
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806142150.OAA12657>