Re: Memory leak on thread removal

2009-05-15 Thread Andriy Tkachuk

On 2009-05-15 14:48, Marius Nünnerich wrote:

Anybody knows good tools how to investigate this?


Valgrind?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: WPA associating with unknown SSID

2008-09-03 Thread Andriy Tkachuk

On 2008-09-03 14:31, Matthias Apitz wrote:

from time to time at home I encounter that it is associating with an
unknown AP of my neighbourhood:

how this is possible and how can I prevent this?
  


Try to get wpa_supplicant log. Also you are welcome to write to 
[EMAIL PROTECTED] mail list about this problem (but specify there 
version of supplicant).



Regards,

  Andriy
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: [FreeBSD-Announce] New Logo

2005-11-02 Thread Andriy Tkachuk
On Tuesday 01 November 2005 18:19, [EMAIL PROTECTED] wrote:
 4.  I sure ain't going to wear a T-shirt with that on it.

sad story - i'm too...
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: hot path optimizations in uma_zalloc() uma_zfree()

2005-07-02 Thread Andriy Tkachuk
I have doubts it will works:

-   item = bucket-ub_bucket[--bucket-ub_cnt];
-1bbe: 66 ff 49 08   decw   0x8(%ecx)
-1bc2: 0f bf 41 08   movswl 0x8(%ecx),%eax
-1bc6: 8b 44 81 14   mov0x14(%ecx,%eax,4),%eax
-1bca: 89 45 f0  mov%eax,0xfff0(%ebp)
+   item = *(--bucket-ub_last);
+1bbe: 8b 51 0c  mov0xc(%ecx),%edx
+1bc1: 8d 42 fc  lea0xfffc(%edx),%eax
+1bc4: 89 41 0c  mov%eax,0xc(%ecx)
+1bc7: 8b 52 fc  mov0xfffc(%edx),%edx
+1bca: 89 55 f0  mov%edx,0xfff0(%ebp)

here even more refereces to memory in your variant.


-   bucket-ub_bucket[bucket-ub_cnt++] = item;
-22b9: 0f bf c2  movswl %dx,%eax
-22bc: 8b 4d 0c  mov0xc(%ebp),%ecx
-22bf: 89 4c 83 14   mov%ecx,0x14(%ebx,%eax,4)
-22c3: 8d 42 01  lea0x1(%edx),%eax
-22c6: 66 89 43 08   mov%ax,0x8(%ebx)
+   *(bucket-ub_last++) = item;
+22b9: 8b 43 0c  mov0xc(%ebx),%eax
+22bc: 8b 55 0c  mov0xc(%ebp),%edx
+22bf: 89 10 mov%edx,(%eax)
+22c1: 83 43 0c 04   addl   $0x4,0xc(%ebx)



- Original Message - 
From: Nikos Ntarmos [EMAIL PROTECTED]
To: ant [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, June 30, 2005 7:31 PM
Subject: Re: hot path optimizations in uma_zalloc()  uma_zfree()


 Hi there.
 
 I wouldn't have gone into this if ant hadn't produced that 10% figure
 for the speed improvement with simply reordering of increments and
 dereferences (although jhb@ reported the speed-up he noticed was much
 less than that).
 
 I attach* a patch that: (i) incorporates ant's exchange of uc_freebucket
 for uc_allocbucket, and (ii) throws away the uma_bucket.ub_cnt counter
 of free bucket entries, in favor of a pointer -- uma_bucket.ub_last --
 to the last free bucket entry. If a simple reordering is capable of
 producing a 10% improvement, this change should do much better, since it
 saves the 'add-' in the 'add-and-dereference' process of using arrays
 and counters. The semantics of the pointer closely follow those of the
 ub_cnt counter: ub_last - ub_bucket should equal the old value of
 ub_cnt.
 
 I grep'ed through the whole source repository and the uses of
 uma_bucket.ub_cnt seem confined within sys/vm/uma_core.c, so this change
 must be quite self-contained -- i.e. the change in the fields of
 uma_bucket doesn't seem to affect any other part of the system. One
 could argue that it may make the code a bit less readable, but it only
 affects uma_core.c, so it may be worth the inconvenience.
 
 I don't have a FreeBSD box around any more, so I can't test this patch.
 Heck, I can't either check it for syntax errors and such, so don't throw
 things at me if this doesn't even compile. Can somebody with the time
 and resources give it a try?
 
 \n\n
 
 * Also online at http://noth.ceid.upatras.gr/Misc/uma_bucket.diff
   to avoid being bitten by mailers auto{wrapp,indent}ing the diff
   content.
 

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: hot path optimizations in uma_zalloc() uma_zfree()

2005-07-01 Thread Andriy Tkachuk

 I ran ministat against your tests with 1000 sockets loop and there isn't a 
 lot 
 of difference in the user times:

it was not supposed to be (the difference in the user times)

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: hot path optimizations in uma_zalloc() uma_zfree()

2005-07-01 Thread Andriy Tkachuk

 On Thursday 30 June 2005 10:35 am, Andriy Tkachuk wrote:
  I just checked the object code - you right, it almost the same:
 
  -   bucket-ub_bucket[bucket-ub_cnt] = item;
  -22b9: 0f bf 43 08   movswl 0x8(%ebx),%eax
  -22bd: 8b 4d 0c  mov0xc(%ebp),%ecx
  -22c0: 89 4c 83 0c   mov%ecx,0xc(%ebx,%eax,4)
  -   bucket-ub_cnt++;
  -22c4: 8d 42 01  lea0x1(%edx),%eax
  -22c7: 66 89 43 08   mov%ax,0x8(%ebx)
  +   bucket-ub_bucket[bucket-ub_cnt++] = item;
  +22b9: 0f bf c2  movswl %dx,%eax
  +22bc: 8b 4d 0c  mov0xc(%ebp),%ecx
  +22bf: 89 4c 83 0c   mov%ecx,0xc(%ebx,%eax,4)
  +22c3: 8d 42 01  lea0x1(%edx),%eax
  +22c6: 66 89 43 08   mov%ax,0x8(%ebx)
 
  but still there is some minor difference in first line.
  I'm not familiar with assembler, can somebody explain
  whether this difference is assential or not?
 
 It just uses the stored value of the variable in %dx instead of loading it 
 from memory at 0x8(%ebx).  When I compiled a simple test program here locally 
 I got identical object code though.

Probaly this is the reason of throughput increasing.
I want to note, that all tests where made on my home workstation.
And each new test was made with new kernel just after rebooting
in ttyv withoud X-server.
I think the noise was not assential.

Ministats against second  third optimization showed this results:
(for different number of sockets created  destroyed in one iteration)

 /usr/src/tools/tools/ministat/ministat -c 99.5 sockloop_stat2_o1_sys_1000 
 sockloop_stat2_o2_sys_1000
x sockloop_stat2_o1_sys_1000
+ sockloop_stat2_o2_sys_1000
+--+
|+  + +  x x  x|
||__A_||___M__A__| |
+--+
N   Min   MaxMedian   AvgStddev
x   3 2.373 2.403 2.381 2.3856667   0.015534907
+   3 2.298  2.34  2.32 2.319   0.021007935
No difference proven at 99.5% confidence
 /usr/src/tools/tools/ministat/ministat -c 99.5 sockloop_stat2_o1_sys_100 
 sockloop_stat2_o2_sys_100
x sockloop_stat2_o1_sys_100
+ sockloop_stat2_o2_sys_100
+--+
|+   + +   xxx |
| |___A__M___| |___AM_||
+--+
N   Min   MaxMedian   AvgStddev
x   3 2.158 2.182 2.174 2.171   0.012220202
+   3 2.062 2.126 2.102 2.097   0.032331615
No difference proven at 99.5% confidence
 /usr/src/tools/tools/ministat/ministat -c 99.5 sockloop_stat2_o1_sys_10 
 sockloop_stat2_o2_sys_10
x sockloop_stat2_o1_sys_10
+ sockloop_stat2_o2_sys_10
+--+
|  +   |
|  +  + x xx   |
||_M_A|  |A___M___||
+--+
N   Min   MaxMedian   AvgStddev
x   3 1.754 1.777 1.776 1.769 0.013
+   3 1.672 1.684 1.673 1.676  0.0066583281
Difference at 99.5% confidence
-0.0926667 +/- 0.060488
-5.23836% +/- 3.41934%
(Student's t, pooled s = 0.010328)
 /usr/src/tools/tools/ministat/ministat -c 99.5 sockloop_stat2_o1_sys_1 
 sockloop_stat2_o2_sys_1
x sockloop_stat2_o1_sys_1
+ sockloop_stat2_o2_sys_1
+--+
|+ +  +x   x  x|
||AM___|  |M_A___| |
+--+
N   Min   MaxMedian   AvgStddev
x   3 1.938 1.993 1.953 1.961   0.028431204
+   3 1.722 1.785 1.759 1.755   0.031659648
Difference at 99.5% confidence
-0.206 +/- 0.176222
-10.5031% +/- 8.98479%
(Student's t, pooled s = 0.0300888)





and for default confidence (95%) this results:

 /usr/src/tools/tools/ministat/ministat sockloop_stat2_o1_sys_1000 
 sockloop_stat2_o2_sys_1000
x sockloop_stat2_o1_sys_1000
+ sockloop_stat2_o2_sys_1000

Re: hot path optimizations in uma_zalloc() uma_zfree()

2005-07-01 Thread Andriy Tkachuk

 if one will decide to commit first optimization (about buckets),
 then there must some adjustments be made also
 regarding correct statistics gathering.

It seems that all is fine with statistics,
i mistook.

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: hot path optimizations in uma_zalloc() uma_zfree()

2005-06-30 Thread Andriy Tkachuk
I just checked the object code - you right, it almost the same:

-   bucket-ub_bucket[bucket-ub_cnt] = item;
-22b9: 0f bf 43 08   movswl 0x8(%ebx),%eax
-22bd: 8b 4d 0c  mov0xc(%ebp),%ecx
-22c0: 89 4c 83 0c   mov%ecx,0xc(%ebx,%eax,4)
-   bucket-ub_cnt++;
-22c4: 8d 42 01  lea0x1(%edx),%eax
-22c7: 66 89 43 08   mov%ax,0x8(%ebx)
+   bucket-ub_bucket[bucket-ub_cnt++] = item;
+22b9: 0f bf c2  movswl %dx,%eax
+22bc: 8b 4d 0c  mov0xc(%ebp),%ecx
+22bf: 89 4c 83 0c   mov%ecx,0xc(%ebx,%eax,4)
+22c3: 8d 42 01  lea0x1(%edx),%eax
+22c6: 66 89 43 08   mov%ax,0x8(%ebx)

but still there is some minor difference in first line.
I'm not familiar with assembler, can somebody explain
whether this difference is assential or not?


in decrementation there is no difference at all:

-   bucket-ub_cnt--;
+   item = bucket-ub_bucket[--bucket-ub_cnt];
 1bbe:  66 ff 49 08 decw   0x8(%ecx)
-   item = bucket-ub_bucket[bucket-ub_cnt];
 1bc2:  0f bf 41 08 movswl 0x8(%ecx),%eax
 1bc6:  8b 44 81 0c mov0xc(%ecx,%eax,4),%eax
 1bca:  89 45 f0mov%eax,0xfff0(%ebp)


- Original Message - 
From: Max Laier [EMAIL PROTECTED]
To: freebsd-hackers@freebsd.org
Cc: ant [EMAIL PROTECTED]
Sent: Thursday, June 30, 2005 3:15 PM
Subject: Re: hot path optimizations in uma_zalloc()  uma_zfree()

 Another optimization is very trivial, for example:
 -   bucket-ub_cnt--;
 -   item = bucket-ub_bucket[bucket-ub_cnt];
 +   item = bucket-ub_bucket[--bucket-ub_cnt];
 (see the patch)

Might be me, but this doesn't change the generated object code at all (modulo 
the changed __line__ in debugging).



___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: vmstat reporting incorrect cpu usage

2005-06-04 Thread Andriy Tkachuk
On Saturday 04 June 2005 17:58, Matt Emmerton wrote:
 The first line is the average since the system was last booted; all other
 lines are instantaneous.

yeap. from man page:

 -c  Repeat the display count times.  The first display is for the
 time since a reboot and each subsequent report is for the time
 period since the last display.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: ext2 drives under 5.3 not umounting on reboots

2005-04-18 Thread Andriy Tkachuk
I've had the same problem on 5.3.
now on my FreeBSD 5.4-RC2 #0: Fri Apr 15 11:28:48 EEST 2005 i386
it seems that problem gone.

On Sunday 17 April 2005 00:07, c0ldbyte wrote:
 On Sat, 16 Apr 2005, M. Parsons wrote:
 
  I have a ext2 linux partition mounted under /linux via the fstab line:
 
  /dev/ad2s1 /linux  ext2fs  rw  1   2
 
  It will automount on bootup, but if I do a reboot or shutdown -h now, it
  doesnt get umounted properly.  In fact, if this /linux is mounted, then /,
  /usr, /var, and /tmp (all seperate ufs slices on another hard drive) also 
  get
  tainted during a reboot.  And on the next startup I get the good ole:
  WARNING: /usr was not properly dismounted, leaving me to fsck the drives in
  single mode (which sucks, as the fbsd machine is a headless NAT machine).
  Running fsck in single mode does fix everything.
 
  So whats going on here?  reboot aint properly umounting partitions, and fsck
  doesnt seem to be properly running during bootup if it detects tainted
  filesystems.
 
  Any ideas?
 
  Freebsd 5.3 SMP kernel.
 
 Try this line:
 /dev/ad2s1 /linux  ext2fs  rw  0   0
 
 But remember the ext2 code has been buggy for a while and is not allways
 a good choice to try and do writes on it. Might be a better choice to
 change rw to ro and to also check that drive/partition for errors with
 its original fsck to fix any errors if there is any then it will most
 likely mount properly and umount properly.
 
 Best of luck,
   --c0ldbyte
 
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re[2]: contributing to fbsd

2005-03-26 Thread Andriy Tkachuk
 If you're interested, I can send you a copy of the code... It's a bare
 implementation with some basic regression tests performed  It doesn't
 layer ontop of kmem_cache though...

Yes, John. Send me please.

Thank you,
  Andriy.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: contributing to fbsd

2005-03-26 Thread Andriy Tkachuk

(exept patching [2005/01/26] threads/76690threads fork hang in child 
for (-lc_r  -lthr)
in wich anyone doesn't interesting as it appeared ))

PRs can get lost or misfiled... it's just human nature.
threads PRs are broadcasted every moth AFAIN )
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


sched_ule, runqueues, priority, and O(1) sheduling question

2005-03-04 Thread Andriy Tkachuk
Hi folks.
I wander how O(1) sheduling works in ULE.
In ule.pdf Jeff wrote:
Threads are picked from the current queue in 
priority order until the current queue is empty.

As far as I understand the algorithm is O(n)
where n - number of READY TO RUN processes,
not all processes isn't it?
thanks,
 Andriy.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


sched_ule, runqueues, priority, and O(1) sheduling question

2005-03-04 Thread Andriy Tkachuk
Hi folks.
I wander how O(1) sheduling works in ULE.
In ule.pdf Jeff wrote:
Threads are picked from the current queue in 
priority order until the current queue is empty.

As far as I understand the algorithm is O(n)
where n - number of READY TO RUN processes,
not all processes isn't it?
thanks,
 Andriy.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: sched_ule, runqueues, priority, and O(1) sheduling question

2005-03-04 Thread Andriy Tkachuk
I haven't looked at it, but could it just be referring to retrieving a 
thread from the queue.  Just pulling something off a queue is a O(1) 
operation.  The order it places things in the queue probably is not. :)
You rihgt - just pulling something off a queue is a O(1) operation,
but before pulling algorithm is finding the thread with highest
priority, with it have to pull  - this is not the O(1) operation.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: giving up on 1 buffers error messsage

2005-02-25 Thread Andriy Tkachuk
It is interesting why threre is no answer for this question so long time,
regardless that it was posted 2 times :)

For me it is also interesting to get the answer for this question
since from time to time i also confused by such msgs on
shutdown.


 syncing disks... 54 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 giving up on 1
 buffers


 Hi,

 I am referring to the message when the code in kern_shutdown.c in bsd
 4.10 is called at the time of boot() system call

 My understanding is that this message tells us that 1 buffer from the
 buffer cache was not successfully flushed to disk, since the last call to
 sync(). Is that right? In that case what happens to this buffer? Is it
 discarded and assume that fsck will fix this on reboot?

 Since the syncer process runs periodically, can this error message be
 avoided if we wait long enough to guarantee flushing to disk (I have tried
 with DELAYS upto 30 seconds but I still get the error sometimes).

 I am actually trying to use this same code at a different point in time
 (not during shutdown, but to take a checkpoint), so I am not sure if that
 contributes to this error message?




 ___
 freebsd-hackers@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
 To unsubscribe, send any mail to [EMAIL PROTECTED]



___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Remote upgrade of 4.X-5.3-Stable

2005-02-24 Thread Andriy Tkachuk
Gentlemen, is this theme for this list?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


pthreads dynamic memory in fbsd vs. the same in linux

2005-02-10 Thread Andriy Tkachuk
Hi folks.

I noticed the strange stick of pthreads (amount ~ 500)
when allocating dynamic memory by malloc or new
in my system:

 uname -a
FreeBSD ant.emict.com 5.3-STABLE FreeBSD 5.3-STABLE #0: Wed Feb  9 17:30:11 EET 
2005 [EMAIL PROTECTED]:/lin/fbsd_obj/usr/src/sys/ANT  i386

It's interesting that the same program behaves differently
when it is compiled in linux and run on my fbsd machine in
linux_base-7.1_7 .

 ldd test2-linux
test2-linux:
libpthread.so.0 = /lib/libpthread.so.0 (0x28065000)
libstdc++-libc6.2-2.so.3 = /usr/lib/libstdc++-libc6.2-2.so.3 
(0x2807c000)
libm.so.6 = /lib/libm.so.6 (0x280bf000)
libc.so.6 = /lib/libc.so.6 (0x280e1000)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x2804c000)
 ldd a.out
a.out:
libpthread.so.1 = /usr/lib/libpthread.so.1 (0x28075000)
libstdc++.so.4 = /usr/lib/libstdc++.so.4 (0x28099000)
libm.so.3 = /lib/libm.so.3 (0x2816b000)
libc.so.5 = /lib/libc.so.5 (0x28184000)


Each thread allocates the amount of memory by 10 bytes in loop.
The number of iterations is specified in cmdline arg. The program
prints the time each thread is spent allocating memory in loop.
Let's look on results.

 ./a.out n 1000  # 1000 iterations of new operator. Every new allocates 
 10bytes.
thread 0 created
thread 1 created
thread 2 created
thread 3 created
thread 4 created
...
thread 497 created
thread 498 created
thread 499 created
0.001114
0.001022
0.001021
0.001011
0.001014
0.001010
0.001013
0.001050
0.001035
0.001011
0.001013
0.001010
0.001013
0.001010
0.001029
0.001075
0.001053
0.001011
0.001014
0.001011
0.001030
0.001010
0.001015
0.001042
0.001019
0.001011
0.001014
0.001012
0.001013
0.001010
0.001014
0.361604
3.225090
3.225458
3.225696
3.225925
3.226152
3.226380
3.226608
3.226833
3.227062
3.227290
3.227517
3.227744
3.227972
3.228202
3.228451
3.228681
3.228912
3.229140
3.229367


The same, but in linux_base-7.1_7 :

 ./test2-linux n 1000
thread 0 created
thread 1 created
...
thread 498 created
thread 499 created
0.000467
0.000403
0.000402
...
0.000391
0.000391
0.000395
...
0.000395
0.010564
0.000398
0.000394


The program source is attached.

In linux program is compiled by
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-98)

in fbsd:
 gcc -v
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.4.2 [FreeBSD] 20040728

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: pthreads dynamic memory in fbsd vs. the same in linux

2005-02-10 Thread Andriy Tkachuk
i sent the mail with attachement. anyway, the code:
(probably the better list would be -threads. sorry folks for flame.
i subscribed today to -threads, so please reply to it if no mind.)

 cat test2.cc
#include pthread.h
#include stdio.h
#include unistd.h
#include sys/time.h
#include string

using std::string;

#define COUNT_THREADS   500

pthread_t   thread[COUNT_THREADS];

char mode;
int iters;

void f()
{
  struct timeval t1,t2;
  void* p[iters];
  string s;

  sleep(2);

  while (1)
  {

gettimeofday(t1, NULL);

if (mode == 's') {
s = ;
for (int i=0; iiters; i++)
s += 'a';
}
if (mode == 'S') {
string s;
for (int i=0; iiters; i++)
s = 'a';
}

if (mode == 'f')
for (int i=0; iiters; i++)
gettimeofday(t2, NULL);

if (mode == 'm') {
for (int i=0; iiters; i++)
p[i] = malloc(10);
for (int i=0; iiters; i++)
free(p[i]);
}
if (mode == 'n') {
for (int i=0; iiters; i++)
p[i] =  (char*) new char(10);
for (int i=0; iiters; i++)
delete (char*) p[i];
}

gettimeofday(t2, NULL);

int usec_d = t2.tv_usec-t1.tv_usec;
int sec_d = t2.tv_sec-t1.tv_sec;
if (usec_d0) {
sec_d--;
usec_d += 100;
}

printf( %u.%06u \n,  sec_d, usec_d);
  }
}


int main(int argc, char *argv[])
{

   mode = argv[1][0];
   iters = atoi(argv[2]);

  for (int i=0; iCOUNT_THREADS; i++) {
 pthread_create ( (thread[i]), NULL, (void*(*)(void*))f, NULL );
 printf(thread %i created\n, i);
  }
  while(1) { sleep(1); }
}


On Thursday 10 February 2005 15:46, Coleman Kane wrote:
 Could you post the code too, perchance?

 On Thu, 10 Feb 2005 10:55:04 +0200, Andriy Tkachuk [EMAIL PROTECTED] wrote:
  Hi folks.
 
  I noticed the strange stick of pthreads (amount ~ 500)
  when allocating dynamic memory by malloc or new
 
  in my system:
   uname -a
 
  FreeBSD ant.emict.com 5.3-STABLE FreeBSD 5.3-STABLE #0: Wed Feb  9
  17:30:11 EET 2005 [EMAIL PROTECTED]:/lin/fbsd_obj/usr/src/sys/ANT  i386
 
  It's interesting that the same program behaves differently
  when it is compiled in linux and run on my fbsd machine in
  linux_base-7.1_7 .
 
   ldd test2-linux
 
  test2-linux:
  libpthread.so.0 = /lib/libpthread.so.0 (0x28065000)
  libstdc++-libc6.2-2.so.3 = /usr/lib/libstdc++-libc6.2-2.so.3
  (0x2807c000) libm.so.6 = /lib/libm.so.6 (0x280bf000)
  libc.so.6 = /lib/libc.so.6 (0x280e1000)
  /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x2804c000)
 
   ldd a.out
 
  a.out:
  libpthread.so.1 = /usr/lib/libpthread.so.1 (0x28075000)
  libstdc++.so.4 = /usr/lib/libstdc++.so.4 (0x28099000)
  libm.so.3 = /lib/libm.so.3 (0x2816b000)
  libc.so.5 = /lib/libc.so.5 (0x28184000)
 
  Each thread allocates the amount of memory by 10 bytes in loop.
  The number of iterations is specified in cmdline arg. The program
  prints the time each thread is spent allocating memory in loop.
  Let's look on results.
 
   ./a.out n 1000  # 1000 iterations of new operator. Every new allocates
   10bytes.
 
  thread 0 created
  thread 1 created
  thread 2 created
  thread 3 created
  thread 4 created
  ...
  thread 497 created
  thread 498 created
  thread 499 created
  0.001114
  0.001022
  0.001021
  0.001011
  0.001014
  0.001010
  0.001013
  0.001050
  0.001035
  0.001011
  0.001013
  0.001010
  0.001013
  0.001010
  0.001029
  0.001075
  0.001053
  0.001011
  0.001014
  0.001011
  0.001030
  0.001010
  0.001015
  0.001042
  0.001019
  0.001011
  0.001014
  0.001012
  0.001013
  0.001010
  0.001014
  0.361604
  3.225090
  3.225458
  3.225696
  3.225925
  3.226152
  3.226380
  3.226608
  3.226833
  3.227062
  3.227290
  3.227517
  3.227744
  3.227972
  3.228202
  3.228451
  3.228681
  3.228912
  3.229140
  3.229367
 
  The same, but in linux_base-7.1_7 :
   ./test2-linux n 1000
 
  thread 0 created
  thread 1 created
  ...
  thread 498 created
  thread 499 created
  0.000467
  0.000403
  0.000402
  ...
  0.000391
  0.000391
  0.000395
  ...
  0.000395
  0.010564
  0.000398
  0.000394
 
  The program source is attached.
 
  In linux program is compiled by
  $ gcc -v
  Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
  gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-98)
 
  in fbsd:
   gcc -v
 
  Using built-in specs.
  Configured with: FreeBSD/i386 system compiler
  Thread model: posix
  gcc version 3.4.2 [FreeBSD] 20040728
 
 
  ___
  freebsd-hackers@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
  To unsubscribe, send any mail to
  [EMAIL PROTECTED]

 ___
 freebsd-hackers@freebsd.org mailing list
 http://lists.freebsd.org

Re: Boot fails: Default F1? hangs. Trashed MBR? replaced FBSD mbr.

2005-02-02 Thread Andriy Tkachuk
maybe the reason you didn't receive any answer about your
problem till now is that you choose the wrong list for your problem

the right one is probably -questions

anyway: you probably lost the partiotion table as well as mbr.
if your filesystems didn't reformatted or erased - all is fine,
you don't have to panic since all your information don't lost.

if you lost your partition table, you can recover.
for this you must find the first sectors of you partitions.
all this recovery staff you should do on some another machine
or booting from fixit cd, but the first is the best.

the first sector of your first slice (let's call it right)
starts probably on 63 sector. create it (fdisk) with some
reasonable size, say 500Mb. after this try disklabel (if it
has several partitions) or fsck to see it's real size.
probably you can use some another util for this - no matter.
the main idia is that you recover you partition table
by content of your partiotions. you may find useful for
this dd(1) and file(1) utils.

sorry i have no time now for bigger explanations,
also i did such staff several years ago (there was even worse
case - i erase the disklabels on fbsd slice) and i don't
remember some exact things, but i think you will overcome this.

regards

On Saturday 29 January 2005 05:01, you wrote:
 Chris Shenton [EMAIL PROTECTED] writes:
  So I booted from floppies, went to Wizard mode, did the Install
  FreeBSD Bootmanager. Rebooted. Now it halts at the prompt Default:
  F1 and beeps when I hit any key, like RETURN, F1, etc.

 Forgot to mention...

 When I was installing the FreeBSD MBR from floppy, I don't recall the
 sysinstall program showing me any partitions, at all.  Perhaps I've
 wiped out the info on disk that says where they are and what size.
 Again, I'm getting way outside my understanding of FreeBSD's boot
 process, but figured this might be rather significant. I'm getting a
 bad feeling about this.

 Thanks again.
 ___
 freebsd-hackers@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
 To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: /bin/ls sorting bug?

2004-06-19 Thread Andriy Tkachuk
 And AFAICS, there's no way to tell ls: first sort on time,
 then on filename, then on size, etc.  This would make a nice addition
 though. :)

But there is nice sort command and power of unix.
Don't you remember the initial UNIX concept to make miracles by small
things fired together? :)


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]