Re: Any success stories for HAST + ZFS?

2011-04-10 Thread Mikolaj Golub

On Mon, 4 Apr 2011 11:08:16 -0700 Freddie Cash wrote:

 FC> Once the deadlock patches above are MFC'd to -STABLE, I can do an
 FC> upgrade cycle and test them.

Committed to STABLE.

-- 
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: geli(4) memory leak

2011-04-10 Thread Mikolaj Golub

On Sun, 03 Apr 2011 20:43:45 +0300 Mikolaj Golub wrote to Pawel Jakub Dawidek:

 MG> On Sat, 2 Apr 2011 12:17:50 +0200 Pawel Jakub Dawidek wrote:

 PJD>> On Sat, Apr 02, 2011 at 12:04:09AM +0300, Mikolaj Golub wrote:
 >>> For me your patch look correct. But the same issue is for read :-). Also, 
 >>> to
 >>> avoid the leak I think we can just do g_destroy_bio() before "all sectors"
 >>> check. See the attached patch (had some testing).

 PJD>> The patch looks good. Please commit.

 MG> Commited, thanks.

In STABLE too.

-- 
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: powerd / cpufreq question

2011-04-10 Thread Ian Smith
On Fri, 8 Apr 2011, Daniel Ger?o wrote:

 > Hello guys,
 > 
 > I have a new machine with Xeon(R) CPU X5650 2666.77-MHz and I would like to
 > utilize powerd(8) on it however, when I run `powerd -v -r90' I see something
 > like this:
 > 
 > load  64%, current freq 2668 MHz ( 0), wanted freq 5336 MHz
 > load 120%, current freq 2668 MHz ( 0), wanted freq 5336 MHz
 > load 173%, current freq 2668 MHz ( 0), wanted freq 5336 MHz
 > load  62%, current freq 2668 MHz ( 0), wanted freq 5336 MHz
 > load  82%, current freq 2668 MHz ( 0), wanted freq 5336 MHz
 > load 110%, current freq 2668 MHz ( 0), wanted freq 5336 MHz
 > 
 > even though the machine is according to top(1) ~90% idle; So I realized, that
 > powerd might take the load as the sum of loads of all the cores (12), so I
 > tried to tweak powerd arguments like this:

Hi Daniel, Alexander, all.

I hope to engage more on this interesting topic later, but first:

[..]

 > Examle of two consecutive cp_times sysctl output:
 > 
 > kern.cp_times: 4182996 0 306925 85623 13563403 3164971 0 201479 93110
 > 14679313 3450792 0 258166 80198 14349717 2795270 0 180252 76701 15086650
 > 2952777 0 217156 119627 14849313 2418067 0 158594 73497 15488715 2408492 0
 > 175131 104377 15450873 2003803 0 131790 75753 15927527 2456736 0 178894 36963
 > 15466280 1607095 0 117396 4197 16410185 2127878 0 147639 30804 15832552
 > 1406621 0 92686 1058 16638508
 > 
 > kern.cp_times: 4183013 0 306927 85626 13563469 3164980 0 201482 93110
 > 14679390 3450796 0 258167 80199 14349800 2795274 0 180252 76701 15086735
 > 2952780 0 217157 119629 14849396 2418070 0 158597 73497 15488798 2408499 0
 > 175132 104377 15450954 2003804 0 131791 75753 15927614 2456744 0 178897 36963
 > 15466358 1607098 0 117398 4197 16410269 2127880 0 147640 30804 15832638
 > 1406621 0 92686 1058 16638597

I wrote the script included below to try making some sense of these, 
that defaults to using your above values, resulting in:

smithi on sola% sh cptimes.sh
  cp_usercp_nice cp_syscp_intrcp_idle
cpu: 0 @t04182996  0 306925  85623   13563403
cpu: 0 @t14183013  0 306927  85626   13563469
   17  0  2  3 66
cpu: 1 @t03164971  0 201479  93110   14679313
cpu: 1 @t13164980  0 201482  93110   14679390
9  0  3  0 77
cpu: 2 @t03450792  0 258166  80198   14349717
cpu: 2 @t13450796  0 258167  80199   14349800
4  0  1  1 83
cpu: 3 @t02795270  0 180252  76701   15086650
cpu: 3 @t12795274  0 180252  76701   15086735
4  0  0  0 85
cpu: 4 @t02952777  0 217156 119627   14849313
cpu: 4 @t12952780  0 217157 119629   14849396
3  0  1  2 83
cpu: 5 @t02418067  0 158594  73497   15488715
cpu: 5 @t12418070  0 158597  73497   15488798
3  0  3  0 83
cpu: 6 @t02408492  0 175131 104377   15450873
cpu: 6 @t12408499  0 175132 104377   15450954
7  0  1  0 81
cpu: 7 @t02003803  0 131790  75753   15927527
cpu: 7 @t12003804  0 131791  75753   15927614
1  0  1  0 87
cpu: 8 @t02456736  0 178894  36963   15466280
cpu: 8 @t12456744  0 178897  36963   15466358
8  0  3  0 78
cpu: 9 @t01607095  0 117396   4197   16410185
cpu: 9 @t11607098  0 117398   4197   16410269
3  0  2  0 84
cpu:10 @t02127878  0 147639  30804   15832552
cpu:10 @t12127880  0 147640  30804   15832638
2  0  1  0 86
cpu:11 @t01406621  0  92686   1058   16638508
cpu:11 @t11406621  0  92686   1058   16638597
0  0  0  0 89

As you see, total of differences for each cpu is here 89 ticks, but I've 
no idea of the interval between your two readings, or your value of HZ?

Are those kern.cp_times values as they came, or did you remove trailing 
zeroes?  Reason I ask is that on my Thinkpad T23, single-core 1133/733 
MHz, sysctl kern.cp_time shows the usual 5 values, but kern.cp_times has 
the same 5 values for cpu0, but then 5 zeroes for each of cpu1 through 
cpu31, on 8.2-PRE about early January.  I need to update the script to 
remove surplus data for non-existing cpus, but wonder if the extra da