On 11 Jun 1999 23:15:15 PDT, Arun Sharma writes:
>Can someone explain to me why is SYSCALL_LOCK necessary ? It certainly
>seems to hurt system call performance on a MP machine.
>
>Also, is there any data on lock contention in FreeBSD ? Is anyone
>working on decomposing some of the giant locks ?
I
At 11:15 PM 6/11/99 -0700, Arun Sharma wrote:
>"David E. Cross" writes:
>
>> Looking through the exception.s it appears that on entry to the
>> kernel an MP lock is obtained... I thought we had splX(); to
>> protect concurancy in the kernel.
>
>Can someone explain to me why is SYSCALL_LOCK necess
It seems Christopher R. Bowman wrote:
[exelent explanation snipped]
> The alternative to the Giant Kernel Lock(tm) is so called fine grained locking
> wherein locking is pushed down closer to the data structures. In fine grained
> locking two processors might be executing in the kernel at the same
FYI, this is brief translation from newconfig-jp ML. New dynamic
loader test patch by Uchiyama san for newconfig kernel is avilable.
Original messages is [newconfig-jp 2107](Subject:
sysnewconfig990609-kld990609test8.7.patch.gz, From: UCHIYAMA Yasushi
, Date: Wed, 09 Jun 1999 03:05:26 +0900)
ftp
We set up open majordomo mailing lists of CVS commit log for Japanese
local CVS repository.
Currently, there are three ML available. To subscribe, send subscribe
command to majord...@jp.freebsd.org as usual:
-
subscribe cvs-newconfig
subscribe cvs-pao
subscribe cvs-pao3
-
# cvs-pao mea
Soren Schmidt said:
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
> It seems Christopher R. Bowman wrote:
> [exelent explanation snipped]
> > The alternative to the Giant Kernel Lock(tm) is so called fine grained
> > locking
> > wherein locking is pushed down closer to the data structure
Wes Peters said:
>
> Try a more meaningful benchmark, one that actually does something in
> the kernel before returning, and see how they do. Try calling kill
> or socket/close a few hundred thousand times and see how they do.
>
Historically, my emphasis on FreeBSD kernel work was to make it wor
Greetings!
I've noticed that questions- frequently gets many people asking about "ld.so"
problems that they've had since upgrading to 3.x from 2.2.x and the answer to
their problem is almost always the same.
Therefore I'd like to make sure that the following information is accurate
before I submi
Aaron Smith writes:
> I'm still trying to figure out the deal with "lockmgr".
I found the following doc useful:
http://www.freebsd.org/~fsmp/SMP/Locking.html
-Arun
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
"Christopher R. Bowman" writes:
>
> I can't speak authoritatively since I don't know specifically what
> SYSCALL_LOCK is, but if it is what is often referred to on this list
> as the Giant Kernel Lock(tm) then the following should generally
> apply.
>
You're right. The SYSCALL_LOCK is the same
"John S. Dyson" writes:
> Finegrained locking either requires developers with IQ's of 200 or higher,
> or a different kernel structure. I suggest that finegrained locking is cool,
> and can be intelligently used to mitigate (but not solve) the effects of
> lots of problems
Fine grained locking
On Sat, 12 Jun 1999, John S. Dyson wrote:
> Soren Schmidt said:
> [Charset ISO-8859-1 unsupported, filtering to ASCII...]
> > It seems Christopher R. Bowman wrote:
> > [exelent explanation snipped]
> > > The alternative to the Giant Kernel Lock(tm) is so called fine grained
> > > locking
> > > wh
On 12 Jun 1999, Arun Sharma wrote:
> "John S. Dyson" writes:
>
> > Finegrained locking either requires developers with IQ's of 200 or higher,
> > or a different kernel structure. I suggest that finegrained locking is
> > cool,
> > and can be intelligently used to mitigate (but not solve) the e
It seems Arun Sharma wrote:
> An alternative way, which requires a good understanding of both the
> theory and implementation of the kernel is -
>
> (a) Implement per subsystem locking
This was exactly what I experimented with some 7-8 month ago, it
showed significant improvements in performance
Soren Schmidt wrote:
>
> It seems Arun Sharma wrote:
> > An alternative way, which requires a good understanding of both the
> > theory and implementation of the kernel is -
> >
> > (a) Implement per subsystem locking
>
> This was exactly what I experimented with some 7-8 month ago, it
> showed s
Thanks conrad..
All the appropriate FreeBSD people were at usenix..
(didn't see you there..)
julian
On Fri, 11 Jun 1999, Conrad Minshall wrote:
> >So far my conclusions
> >have led me to a race in unlink and NFS somewhere (still have no clue where).
> >And it is only from Sun clients to da
Brian Feldman writes:
> > One way of tackling the problem is - to implement per lock profiling
> > and detect which locks are being contested heavily and try breaking
> > them down. That would be a practical way of doing things.
>
> But you can't generalize FreeBSD's usage, can you?
>
While i
> "John S. Dyson" writes:
>
> > Finegrained locking either requires developers with IQ's of 200 or higher,
> > or a different kernel structure. I suggest that finegrained locking is
> > cool,
> > and can be intelligently used to mitigate (but not solve) the effects of
> > lots of problems
>
>
>
> Wes Peters said:
> >
> > Try a more meaningful benchmark, one that actually does something in
> > the kernel before returning, and see how they do. Try calling kill
> > or socket/close a few hundred thousand times and see how they do.
This will only test how fast the kernel memory allocator
> I agree. However, I suggest that finegrained locking will be a loosing
> proposition. Something in-between is probably good. My brains got fried
> on trying to figure out a GOOD solution for the FreeBSD kernel. There
> are no GOOD solutions, but a reasonable compromise is some kind of medium
Quota crash my system after quotaoff followed by quotaon!
I applied a patch (kern/8137), but it did not work!
Can anybody explain how could i fix this problem.
here goes the patch i applied:
*** ufs_quota.c Tue Jul 9 12:51:17 1996
--- /net/www/home/pammy/ufs_quota.c Sat Oct 3 13:25:05 19
>
> > Think of it like this: since alot of desktops sit in idle loops much
> > of the time, perhaps the Linux philosophy has been to improve such
> > behavior :-).
>
> The Linux philosophy already has better performance and will also get
> you much stronger TCP/IP user land copy performance unde
Interesting. It's an overlapping same-process deadlock with mmap/write.
This bug also hits NFS, though in a slightly different way, and also
occurs with mmap/write when two processes are mmap'ing two files and
write()ing the other descriptor using the map as a buffer.
I see a
I'm using the attached program which I wrote today (don't ask why, I think
I just wanted to beat the heck out of FreeBSD!) I have maxusers 200, a
MAXFILES=65536, and the limits set to allow me to use the program
fully (all 3 ports; I don't want to monopolize EVERY port...) When
run, select do
Bill Huey wrote:
>
> > Think of it like this: since alot of desktops sit in idle loops much
> > of the time, perhaps the Linux philosophy has been to improve such
> > behavior :-).
>
> The Linux philosophy already has better performance and will also get
> you much stronger TCP/IP user land copy
On Sun, 13 Jun 1999, Brian Feldman wrote:
> I'm using the attached program which I wrote today (don't ask why, I think
> I just wanted to beat the heck out of FreeBSD!) I have maxusers 200, a
> MAXFILES=65536, and the limits set to allow me to use the program
> fully (all 3 ports; I don't wa
> The Linux philosophy has always been about simplistic cycle counting
> exercises without understand whether the data had any meaning or not.
> You've once again displayed your wholehearted participation in this
> lack of understanding of what the data points might mean to any real-
> world appl
On Sat, Jun 12, 1999 at 12:13:43AM -0500, David Scheidt wrote:
> I had a 3.2 stable (from 30 May 1999)machine panic tonight, trying
> to load the oss driver, which is not too shocking. What was shocking
> was the damage done to my filesystem. The automatic fsck failed,
> with an UNEXPECTED SOFT U
28 matches
Mail list logo
