> 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
> 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
>
> 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
> 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.
Or that horribily impracticle wake-one semantics implemented under
SMP for the accept()
> : This is always good, assuming that this is done properly with peer review
> : and that folks listen to it.
>
> Linux isn't peer reviewed in the traditional sense of this meaning, so
> your whole argument fails because of that. I'd agree if it was
> entensively peer reviewed, it might be a goo
> You say that as if it's a good thing... I'd amend it to "The Linux
> camp seems to think it's a good idea to ignore countless man-years of
> research and development in the field of OS design, and make the same
> mistakes other people have made, corrected and documented years before
> them. I ha
> I've been following this conversation with growing concern. It seems
> to me there is a fairly simple solution to this problem: create a
> branch for the ongoing VM work, enable commit privs on the branch for
> Matt and anyone else who's going to join in the fun, and then at times
> when they
> Inter-UNIX rivalries are one of things that has kept unix healthy for so
> long. Linux tends to pick up most of the 3L1t3 dudez, who don't know
You must be joking me. Just about every other systems person I've talked
to in past 5 years, (including me) would highly disagree with that citing
tha
> Context. When people complain about Linux users expecting everything
> to work like Linux, then it's usually safe to assume that the behavior
> in question *does* vary between Linux and other Unix systems, or at
> lease Linux and FreeBSD.
Possibly, but the thing that bothers me is that I've he
> Making such a script is specifically targetted at a small group of
> users; those accustomed to the Linux way of doing things and too
> inflexible or untalented to learn a new way.
The Linux way of doing things isn't terribly different than any other
Unix based OS out there. I don't really un
subscribe freebsd-hackers
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
subscribe bi...@mag.ucsd.edu
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
12 matches
Mail list logo
