Ricardo A. Reis wrote:
Hi George,
pthread_create: Resource temporarily unavailable
Which version of FreeBSD please?
I test libmicro in 6.0-RELEASE and last cvsuped RELENG_6, both doesn't
work.
Thanks
Ricardo A. Reis
UNIFESP
Unix and Network Admin
the pthread_create
e each thread
defaults has 2M stack, you will out of address space.
David Xu
___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Ricardo A. Reis wrote:
>>You can not create 4 threads, because each thread
>>defaults has 2M stack, you will out of address space.
David,
I don't attempt to create 40k threads, i barely increase the limit for
single process for 40k.
I like a test libmicro with default sets.
Ricardo A.
bytes
vmemoryuse infinity kB
if address space is not large enough, you have to reconfigure kernel
to allow larger space. Fix me if I am wrong.
David Xu
___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/free
almost follows every network I/O.
Also you can find its I/O size:
http://people.freebsd.org/~davidxu/mysql/iosize.txt
I guess the gettimeofday() call is relevant to mysql's
connection keepalive work, sounds like a very silly method.
David Xu
___
freebs
smack significantly.
David Xu
___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
/archives/2005/12/12/252/
It it first time that I heard that one can map LINUXTHREADS
to libthr or others by using libmap.conf, can anyone confirm
it is possible ?
David Xu
___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org
sed several times
in the list, I don't want to repeat it here.
David Xu
___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
d to narrow down some
kernel performance problem.
Regards,
David Xu
___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
uses M:N threads which means a thread may be on
userland scheduler's run queue, and FreeBSD kernel does not know,
so it will be not shown on average load, default system tools are not
very useful here.
David Xu
___
freebsd-performance@freebsd.org
On Saturday 08 April 2006 17:44, Michael Vince wrote:
> I have also tried putting my Perl under libthr for a single thread log
> analyzer and to my surprise it even could process logs faster.
>
I don't know why, but I only know I did some micro optimizations in libthr,
and the library is small and
mbol
overriding never works correctly, if you have any idea, we can discuss
it on arch@, we of course will be at disadvantageous position if it won't
be fixed.
> You can find the updated picture at the previous link.
David Xu
___
freebsd-pe
On Saturday 06 May 2006 22:16, Robert Watson wrote:
> Dear all,
>
> Attached, please find a patch implementing more fine-grained locking for
> the POSIX local socket subsystem (UNIX domain socket subsystem). In the
> current implementation, we use a single global subsystem lock to protect
> all lo
On Monday 08 May 2006 07:04, Kris Kennaway wrote:
> i.e. apparently not a large difference, but still a large proportion
> of cases where multiple CPUs are woken at once on the same chain.
>
> Kris
This becauses there is no sleepable mutex available, so I had to use
msleep and wakeup, this is subo
next question is how can that be optimized?
>
may use atomic_cmpset_int in a loop to avoid context switch or use an
adaptive mutex, but there is no adaptive mutex type you can specify.
rlim_t is a 64bit integer, so atomic operation can not be used, but 64bit
integer might not be necessary f
On Tuesday 09 May 2006 02:43, Kris Kennaway wrote:
> Hmm, with this patch mysql 4.1 seems to crash at startup. I haven't
> yet had time to investigate. Is anyone else seeing this?
>
> Kris
I only have tested mysql 4.0, I will try 4.1 later.
___
freebs
On Wednesday 10 May 2006 02:23, Kris Kennaway wrote:
> There are at least several issues here:
>
> * Factor of >two difference in performance across the board (all
> loads) relative to Linux. This may be general issues like
> gettimeofday() on Linux vs FreeBSD; clearly there is something *very
> b
ss of the kernel
page ? do you use fixed address or tell it via program headers like
the PT_TLS set by kernel, check /usr/src/lib/libc/gen/tls.c.
David Xu
___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/fr
he file, so any change in the vendor branch (FreeBSD CVS)
> will put the entire file into conflict. To be specific: I'll track and own
> this, but want to avoid having it in P4 indefinitely, because it will get
> stale :-).
>
> Robert N M Watson
Your patch
protected by scheduler lock,
and delivering a signal to process has to hold scheduler lock and
find a thread, if the proc has many threads, this will introduce
long scheduler latency, a proc lock is not enough to find a thread,
this is a bug, there are other code abusing scheduler lock which
really
cro-benchmark
> performance should show a small loss, but load under contention and
> scalability are (ideally) improved.
>
> Robert N M Watson
> Computer Laboratory
> University of Cambridge
>
I found 5% performance decrease on dual P4, mayb
On Tuesday 27 June 2006 11:34, Greg 'groggy' Lehey wrote:
> This is not the case for Linux, where fsync syncs the entire file
> system. That could explain some of the performance difference, but
> not all of it. I suppose it's worth noting that, in general, people
> report much better performanc
mance, you can forcely turn it off by:
sysctl kern.threads.thr_scope=2
the proc scope support may be dropped near future in libthr, thanks for
your evaluation.
David Xu
___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/ma
e the scheduler works properly.
David Xu
___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
On Tuesday 04 July 2006 02:40, Mike Jakubik wrote:
> Michael Vince wrote:
> > HTT was Intels best early stab to help path the way for their multi
> > core technologies to come into use as quickly as possible for the
> > masses over just the server end.
>
> Exactly, thats why i wouldn't spend too mu
On Tuesday 04 July 2006 06:21, David Xu wrote:
> For conroe, google the "fair-cache", you may find what should be done
> in scheduler, that's one of many reasons why I was saying libpthread should
> be stopped. Unless conroe is very special and does not need this
>
I can get on athlon64 X2 3800+ running in
64-bit mode.
David Xu
___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
t;
> --
> Dave
Thanks for your benchmark result! so it blows away the rumor that our thread
library is slow.
David Xu
___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
my idea, but I think Linux has lots
of tweaks, such as using MMX instruction to copy data.
Regards,
David Xu
___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any
es boundary,
it will not use FPU to copy data, but user buffer is not always 16 bytes
aligned.
David Xu
___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
really works well, in kernel, if the thread
scheduling policy is SCHED_OTHER (time-sharing), scheduler temporarily
lowers its priority to PRI_MAX_TIMESHARE, it is enough to give some CPU
time to other threads. Why doesn't the UNIX time-sharing work for
slower than 4BSD when testing super-smack's update benchmark on my
dual-core machine.
Regards,
David Xu
___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to &q
BSD.
with cpuset, one even can bind all real-time processes to a specific
cpu group, they needn't to be a superuser to run real-time thread.
Regards,
David Xu
___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/list
process-shared, and is more light weight than SYSV semaphore,
if there is no contention, a process need not enter kernel to
acquire/release a lock. Note that I have just fixed a bug in head
branch. However RELENG_8 does not support process-shared semaphore
yet.
Regards,
David Xu
Ivan Voras wrote:
On 11/23/10 01:26, Ivan Voras wrote:
On 11/22/10 17:37, David Xu wrote:
Mark Felder wrote:
I recommend posting this on the Postgres performance list, too.
Regards,
Mark
I think if PostgreSQL uses semaphore for inter-process locking,
it might be a good idea to use
Ivan Voras wrote:
On 23 November 2010 10:35, David Xu wrote:
Ivan Voras wrote:
and the overall behaviour is similar - the processes spend a lot of time
in "sbwait" and "ksem" states.
Strange, the POSIX semaphore in head branch does not use ksem, it is
based on umtx,
On 2013/06/13 20:01, Remy Nonnenmacher wrote:
On 06/13/13 13:32, Mark Felder wrote:
On Wed, 12 Jun 2013 17:58:49 -0500, David O'Brien
wrote:
We found FreeBSD 8.4 to perform better than FreeBSD 9.1, and Linux
considerably better than both on the same machine.
http://svnweb.freebsd.org/base?
37 matches
Mail list logo
