On Oct 4, 2012, at 12:36 AM, Rick Macklem wrote:
> Garrett Wollman wrote:
>> <> said:
>>
Simple: just use a sepatate mutex for each list that a cache entry
is on, rather than a global lock for everything. This would reduce
the mutex contention, but I'm not sure how significantly
On Oct 4, 2012, at 12:36 AM, Rick Macklem wrote:
> Garrett Wollman wrote:
>> <> said:
>>
Simple: just use a sepatate mutex for each list that a cache entry
is on, rather than a global lock for everything. This would reduce
the mutex contention, but I'm not sure how significantly
On Oct 9, 2012, at 5:12 PM, Nikolay Denev wrote:
>
> On Oct 4, 2012, at 12:36 AM, Rick Macklem wrote:
>
>> Garrett Wollman wrote:
>>> <>> said:
>>>
>>>>> Simple: just use a sepatate mutex for each list that a cache entry
>>
On Oct 10, 2012, at 3:18 AM, Rick Macklem wrote:
> Nikolay Denev wrote:
>> On Oct 4, 2012, at 12:36 AM, Rick Macklem
>> wrote:
>>
>>> Garrett Wollman wrote:
>>>> <>>> said:
>>>>
>>>>>> Simple: just use
On Oct 11, 2012, at 1:09 AM, Rick Macklem wrote:
> Nikolay Denev wrote:
>> On Oct 10, 2012, at 3:18 AM, Rick Macklem
>> wrote:
>>
>>> Nikolay Denev wrote:
>>>> On Oct 4, 2012, at 12:36 AM, Rick Macklem
>>>> wrote:
On Oct 11, 2012, at 8:46 AM, Nikolay Denev wrote:
>
> On Oct 11, 2012, at 1:09 AM, Rick Macklem wrote:
>
>> Nikolay Denev wrote:
>>> On Oct 10, 2012, at 3:18 AM, Rick Macklem
>>> wrote:
>>>
>>>> Nikolay Denev wrote:
>&g
On Oct 11, 2012, at 7:20 PM, Nikolay Denev wrote:
> On Oct 11, 2012, at 8:46 AM, Nikolay Denev wrote:
>
>>
>> On Oct 11, 2012, at 1:09 AM, Rick Macklem wrote:
>>
>>> Nikolay Denev wrote:
>>>> On Oct 10, 2012, at 3:18 AM, Rick Macklem
>>&
On Oct 13, 2012, at 5:05 AM, Rick Macklem wrote:
> I wrote:
>> Oops, I didn't get the "readahead" option description
>> quite right in the last post. The default read ahead
>> is 1, which does result in "rsize * 2", since there is
>> the read + 1 readahead.
>>
>> "rsize * 16" would actually be
On Oct 15, 2012, at 2:52 PM, Ivan Voras wrote:
> On 13/10/2012 17:22, Nikolay Denev wrote:
>
>> drc3.patch applied and build cleanly and shows nice improvement!
>>
>> I've done a quick benchmark using iozone over the NFS mount from the Linux
>> host.
&
On Oct 15, 2012, at 2:52 PM, Ivan Voras wrote:
> On 13/10/2012 17:22, Nikolay Denev wrote:
>
>> drc3.patch applied and build cleanly and shows nice improvement!
>>
>> I've done a quick benchmark using iozone over the NFS mount from the Linux
>> host.
&
On Oct 18, 2012, at 3:08 AM, Tristan Verniquet wrote:
>
> I want to work with large (1-10G) files in memory but eventually sync them
> back out to disk. The problem is that the sync process appears to lock the
> file in kernel for the duration of the sync, which can run into minutes. This
>
On Oct 15, 2012, at 5:34 PM, Ivan Voras wrote:
> On 15 October 2012 16:31, Nikolay Denev wrote:
>>
>> On Oct 15, 2012, at 2:52 PM, Ivan Voras wrote:
>
>>> http://people.freebsd.org/~ivoras/diffs/nfscache_lock.patch
>>>
>>> It should apply to HEA
On Oct 18, 2012, at 6:11 PM, Nikolay Denev wrote:
>
> On Oct 15, 2012, at 5:34 PM, Ivan Voras wrote:
>
>> On 15 October 2012 16:31, Nikolay Denev wrote:
>>>
>>> On Oct 15, 2012, at 2:52 PM, Ivan Voras wrote:
>>
>>>> http://p
On Oct 20, 2012, at 3:11 PM, Ivan Voras wrote:
> On 20 October 2012 13:42, Nikolay Denev wrote:
>
>> Here are the results from testing both patches :
>> http://home.totalterror.net/freebsd/nfstest/results.html
>> Both tests ran for about 14 hours ( a bit too much,
On Oct 20, 2012, at 3:11 PM, Ivan Voras wrote:
> On 20 October 2012 13:42, Nikolay Denev wrote:
>
>> Here are the results from testing both patches :
>> http://home.totalterror.net/freebsd/nfstest/results.html
>> Both tests ran for about 14 hours ( a bit too much,
On Oct 20, 2012, at 4:00 PM, Nikolay Denev wrote:
>
> On Oct 20, 2012, at 3:11 PM, Ivan Voras wrote:
>
>> On 20 October 2012 13:42, Nikolay Denev wrote:
>>
>>> Here are the results from testing both patches :
>>> http://home.totalterror.net/freebsd/
On Oct 20, 2012, at 10:45 PM, Outback Dingo wrote:
> On Sat, Oct 20, 2012 at 3:28 PM, Ivan Voras wrote:
>> On 20 October 2012 14:45, Rick Macklem wrote:
>>> Ivan Voras wrote:
>>
I don't know how to interpret the rise in context switches; as this is
kernel code, I'd expect no context
On Oct 23, 2012, at 2:36 AM, Rick Macklem wrote:
> Ivan Voras wrote:
>> On 20 October 2012 13:42, Nikolay Denev wrote:
>>
>>> Here are the results from testing both patches :
>>> http://home.totalterror.net/freebsd/nfstest/results.html
>>> Both tes
On Nov 7, 2012, at 4:48 PM, Wojciech Puchar
wrote:
>>>
>>> actually FreeBSD defaults are actually good for COMMON usage. and can be
>>> tuned.
>>>
>>> default MAXBSIZE is one exception.
>>
>> "Common usage" is vague. While FreeBSD might do ok for some applications
>> (dev box, simple works
On Nov 8, 2012, at 12:56 PM, Wojciech Puchar
wrote:
>> EC> That thread starts here:
>> EC> http://lists.freebsd.org/pipermail/freebsd-arch/2010-April/010143.html
>> Year 2010! And we still limited by MAXPHYS (128K) transfers :(
> put
> options MAXPHYS=2097152
> in your kernel config.
>
On Jan 23, 2013, at 11:09 PM, Mark Felder wrote:
> On Wed, 23 Jan 2013 14:26:43 -0600, Chris Rees wrote:
>
>>
>> So we have to take your word for it?
>> Provide a link if you're going to make assertions, or they're no more than
>> your own opinion.
>
> I've heard this same thing -- every vde
On Jan 24, 2013, at 4:24 PM, Wojciech Puchar
wrote:
>>
> Except it is on paper reliability.
This "on paper" reliability saved my ass numerous times.
For example I had one home NAS server machine with flaky SATA controller that
would not detect one of the four drives from time to time on reboo
space?
--
Regards,
Nikolay Denev
___
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"
23 matches
Mail list logo
