On Wednesday, September 10, 2014 11:29:21 PM Slawa Olhovchenkov wrote:
> On Wed, Sep 10, 2014 at 02:29:30PM -0400, John Baldwin wrote:
> > > Application must change behaviour when reach limit (run GC, switch
> > > algorithm and etc.).
> > > But mmap of big data file for scaning and processing don't
On Wed, Sep 10, 2014 at 02:29:30PM -0400, John Baldwin wrote:
> > Application must change behaviour when reach limit (run GC, switch
> > algorithm and etc.).
> > But mmap of big data file for scaning and processing don't touch this
> > limit.
> > Must be mmap of some temoprary file touch this limi
On Wednesday, September 10, 2014 08:30:58 PM Slawa Olhovchenkov wrote:
> On Wed, Sep 10, 2014 at 10:44:46AM -0400, John Baldwin wrote:
> > On Tuesday, September 09, 2014 02:25:18 PM Slawa Olhovchenkov wrote:
> > > On Mon, Sep 08, 2014 at 11:17:51AM -0400, John Baldwin wrote:
> > > > On Sunday, Sept
On Wed, Sep 10, 2014 at 10:44:46AM -0400, John Baldwin wrote:
> On Tuesday, September 09, 2014 02:25:18 PM Slawa Olhovchenkov wrote:
> > On Mon, Sep 08, 2014 at 11:17:51AM -0400, John Baldwin wrote:
> > > On Sunday, September 07, 2014 04:56:49 PM Slawa Olhovchenkov wrote:
> > > > PS: very bad that
On Tuesday, September 09, 2014 02:25:18 PM Slawa Olhovchenkov wrote:
> On Mon, Sep 08, 2014 at 11:17:51AM -0400, John Baldwin wrote:
> > On Sunday, September 07, 2014 04:56:49 PM Slawa Olhovchenkov wrote:
> > > PS: very bad that 'data limit' don't anymore reflect application
> > > memory consumer.
On Mon, Sep 08, 2014 at 11:17:51AM -0400, John Baldwin wrote:
> On Sunday, September 07, 2014 04:56:49 PM Slawa Olhovchenkov wrote:
> > PS: very bad that 'data limit' don't anymore reflect application
> > memory consumer. and very small application can adapt to 'no memory'
> > from system.
>
> Yo
On Fri, Sep 05, 2014 at 12:23:26PM +0300, Andriy Gapon wrote:
> on 04/09/2014 04:18 Steven Hartland said the following:
> > Indeed that would be interesting, but we might find that its quite memory
> > size
> > dependent given the scaling so confirming HW details would be nice too.
> >
> > I'd a
On 2014-09-03 21:18, Steven Hartland wrote:
- Original Message - From: "Andriy Gapon"
on 03/09/2014 23:22 Nikolai Lifanov said the following:
On 09/03/14 15:22, John Baldwin wrote:
On Wednesday, September 03, 2014 11:05:04 AM Nikolai Lifanov wrote:
On 09/03/14 04:09, Steven Hartlan
On Sunday, September 07, 2014 04:56:49 PM Slawa Olhovchenkov wrote:
> PS: very bad that 'data limit' don't anymore reflect application
> memory consumer. and very small application can adapt to 'no memory'
> from system.
You can use RLIMIT_AS instead of RLIMIT_DATA. jemalloc can also be configure
on 04/09/2014 04:18 Steven Hartland said the following:
> Indeed that would be interesting, but we might find that its quite memory size
> dependent given the scaling so confirming HW details would be nice too.
>
> I'd also be interested to know who wins the free race between the VM and ARC
> when
On 09/03/14 21:18, Steven Hartland wrote:
>
> - Original Message - From: "Andriy Gapon"
>
>
>> on 03/09/2014 23:22 Nikolai Lifanov said the following:
>>> On 09/03/14 15:22, John Baldwin wrote:
On Wednesday, September 03, 2014 11:05:04 AM Nikolai Lifanov wrote:
> On 09/03/14 04
- Original Message -
From: "Andriy Gapon"
on 03/09/2014 23:22 Nikolai Lifanov said the following:
On 09/03/14 15:22, John Baldwin wrote:
On Wednesday, September 03, 2014 11:05:04 AM Nikolai Lifanov wrote:
On 09/03/14 04:09, Steven Hartland wrote:
I'm looking to MFC this change s
on 03/09/2014 23:22 Nikolai Lifanov said the following:
> On 09/03/14 15:22, John Baldwin wrote:
>> On Wednesday, September 03, 2014 11:05:04 AM Nikolai Lifanov wrote:
>>> On 09/03/14 04:09, Steven Hartland wrote:
I'm looking to MFC this change so wanted to check if
anyone had an final fe
On 09/03/14 15:22, John Baldwin wrote:
> On Wednesday, September 03, 2014 11:05:04 AM Nikolai Lifanov wrote:
>> On 09/03/14 04:09, Steven Hartland wrote:
>>> I'm looking to MFC this change so wanted to check if
>>> anyone had an final feedback / objections?
>>>
>>> I know we currently have Alan's f
On Wednesday, September 03, 2014 11:05:04 AM Nikolai Lifanov wrote:
> On 09/03/14 04:09, Steven Hartland wrote:
> > I'm looking to MFC this change so wanted to check if
> > anyone had an final feedback / objections?
> >
> > I know we currently have Alan's feedback on changing
> > the #ifdef __i386
on 03/09/2014 17:58 Andriy Gapon said the following:
> on 03/09/2014 15:17 Steven Hartland said the following:
>> - Original Message - From: "Andriy Gapon"
>>
>>> on 03/09/2014 11:09 Steven Hartland said the following:
I'm looking to MFC this change so wanted to check if
anyone h
On 09/03/14 04:09, Steven Hartland wrote:
> I'm looking to MFC this change so wanted to check if
> anyone had an final feedback / objections?
>
> I know we currently have Alan's feedback on changing
> the #ifdef __i386__ to #ifndef UMA_MD_SMALL_ALLOC
> which sounds sensible but waiting Peter to co
on 03/09/2014 15:17 Steven Hartland said the following:
> - Original Message - From: "Andriy Gapon"
>
>> on 03/09/2014 11:09 Steven Hartland said the following:
>>> I'm looking to MFC this change so wanted to check if
>>> anyone had an final feedback / objections?
>>
>> I think that your
- Original Message -
From: "Andriy Gapon"
on 03/09/2014 11:09 Steven Hartland said the following:
I'm looking to MFC this change so wanted to check if
anyone had an final feedback / objections?
I think that your changes went in a bit prematurely (little review), so perhaps
MFC would
on 03/09/2014 11:09 Steven Hartland said the following:
> I'm looking to MFC this change so wanted to check if
> anyone had an final feedback / objections?
I think that your changes went in a bit prematurely (little review), so perhaps
MFC would be premature as well.
> I know we currently have Al
- Original Message -
From: "Andriy Gapon"
on 02/09/2014 20:43 Steven Hartland said the following:
- Original Message - From: "Andriy Gapon"
And the newly added kmem_foo() functions probably do not belong in
cddl/compat/opensolaris as Solaris / illumos does not have those fun
on 02/09/2014 20:43 Steven Hartland said the following:
> - Original Message - From: "Andriy Gapon"
>> And the newly added kmem_foo() functions probably do not belong in
>> cddl/compat/opensolaris as Solaris / illumos does not have those functions.
>
> They could be moved but their curren
I'm looking to MFC this change so wanted to check if
anyone had an final feedback / objections?
I know we currently have Alan's feedback on changing
the #ifdef __i386__ to #ifndef UMA_MD_SMALL_ALLOC
which sounds sensible but waiting Peter to comment on.
Regards
Steve
__
On 09/02/2014 14:09, Steven Hartland wrote:
> - Original Message - From: "Alan Cox"
>> On 09/02/2014 12:34, Steven Hartland wrote:
>>> - Original Message - From: "Alan Cox"
The patch actually makes two completely orthogonal changes at once,
and
one of those changes
- Original Message -
From: "Alan Cox"
On 09/02/2014 12:34, Steven Hartland wrote:
- Original Message - From: "Alan Cox"
The patch actually makes two completely orthogonal changes at once, and
one of those changes has no connection to the page daemon. I suspect
that is why som
On 09/02/2014 12:34, Steven Hartland wrote:
> - Original Message - From: "Alan Cox"
>
>> On 09/02/2014 11:01, John Baldwin wrote:
>>> On Saturday, August 30, 2014 1:37:43 pm Peter Wemm wrote:
On Saturday 30 August 2014 02:03:42 Steven Hartland wrote:
I'm very disappointed in the
- Original Message -
From: "Andriy Gapon"
on 02/09/2014 19:01 John Baldwin said the following:
I know Steven has since committed a fix, but if there are still
concerns, I
think it would be best to not just revert this entirely but to spend
some time
fixing the remaining issues. Clea
- Original Message -
From: "Alan Cox"
On 09/02/2014 11:01, John Baldwin wrote:
On Saturday, August 30, 2014 1:37:43 pm Peter Wemm wrote:
On Saturday 30 August 2014 02:03:42 Steven Hartland wrote:
I'm very disappointed in the attention to detail and errors in the commit.
I'm almost
On 09/02/2014 11:01, John Baldwin wrote:
> On Saturday, August 30, 2014 1:37:43 pm Peter Wemm wrote:
>> On Saturday 30 August 2014 02:03:42 Steven Hartland wrote:
>> I'm very disappointed in the attention to detail and errors in the commit.
>> I'm almost at the point where I want to ask for the w
on 02/09/2014 19:01 John Baldwin said the following:
> I know Steven has since committed a fix, but if there are still concerns, I
> think it would be best to not just revert this entirely but to spend some
> time
> fixing the remaining issues. Clearly this issue affects a lot of users and
>
On Saturday, August 30, 2014 1:37:43 pm Peter Wemm wrote:
> On Saturday 30 August 2014 02:03:42 Steven Hartland wrote:
> I'm very disappointed in the attention to detail and errors in the commit.
> I'm almost at the point where I want to ask for the whole thing to be backed
> out.
I would not b
- Original Message -
From: "Peter Wemm"
snip...
> I'm aware of the values involved, and as I said what you're
> proposing
> was more akin to where I started, but I was informed that it had
> already
> been tested and didn't work well.
And Karl also said that his tests are on machines
On Saturday 30 August 2014 02:03:42 Steven Hartland wrote:
> - Original Message -
> From: "Peter Wemm"
>
> > On Friday 29 August 2014 21:42:15 Steven Hartland wrote:
>
> > If this function returns non-zerp, ARC is given back:
> >
> > static int
> > arc_reclaim_needed(void)
> > {
> >
>
- Original Message -
From: "Peter Wemm"
On Friday 29 August 2014 21:42:15 Steven Hartland wrote:
> - Original Message -
> From: "Peter Wemm"
>
> > On Friday 29 August 2014 20:51:03 Steven Hartland wrote:
> snip..
>
> > > Does Karl's explaination as to why this doesn't work abo
On Friday 29 August 2014 21:42:15 Steven Hartland wrote:
> - Original Message -
> From: "Peter Wemm"
>
> > On Friday 29 August 2014 20:51:03 Steven Hartland wrote:
> snip..
>
> > > Does Karl's explaination as to why this doesn't work above change
> > > your
> > > mind?
> >
> > Actually
- Original Message -
From: "Peter Wemm"
On Friday 29 August 2014 20:51:03 Steven Hartland wrote:
snip..
> Does Karl's explaination as to why this doesn't work above change
> your
> mind?
Actually no, I would expect the code as committed would *cause* the
undesirable behavior that
On Friday 29 August 2014 20:51:03 Steven Hartland wrote:
> > On Friday 29 August 2014 11:54:42 Alan Cox wrote:
> snip...
> > > > With the patch we confirmed that both RAM usage and performance
> > > > for those
> > > > seeing that issue are resolved, with no reported regressions.
> > > >
> > > >>
- Original Message -
From: "Steven Hartland"
- Original Message -
From: "Alan Cox"
You didn't really address Peter's initial technical issue. Peter
correctly observed that cache pages are just another flavor of free
pages. Whenever the VM system is checking the number of
- Original Message -
From: "Alan Cox"
You didn't really address Peter's initial technical issue. Peter
correctly observed that cache pages are just another flavor of free
pages. Whenever the VM system is checking the number of free pages
against any of the thresholds, it always uses
On Friday 29 August 2014 11:54:42 Alan Cox wrote:
snip...
> > Others have also confirmed that even with r265945 they can still
> > trigger
> > performance issue.
> >
> > In addition without it we still have loads of RAM sat their
> > unused, in my
> > particular experience we have 40GB of 192
On Friday 29 August 2014 11:54:42 Alan Cox wrote:
> On 08/29/2014 03:32, Steven Hartland wrote:
> >> On Thursday 28 August 2014 17:30:17 Alan Cox wrote:
> >> > On 08/28/2014 16:15, Matthew D. Fuller wrote:
> >> > > On Thu, Aug 28, 2014 at 10:11:39PM +0100 I heard the voice of
> >> > >
> >> > > Ste
On 08/29/2014 03:32, Steven Hartland wrote:
>> On Thursday 28 August 2014 17:30:17 Alan Cox wrote:
>> > On 08/28/2014 16:15, Matthew D. Fuller wrote:
>> > > On Thu, Aug 28, 2014 at 10:11:39PM +0100 I heard the voice of
>> > >
>> > > Steven Hartland, and lo! it spake thus:
>> > >> Its very likely ap
On 8/28/2014 6:22 PM, Peter Wemm wrote:
[...]
> vm_paging_needed(void)
> {
> return (vm_cnt.v_free_count + vm_cnt.v_cache_count <
> vm_pageout_wakeup_thresh);
> }
By the way there is a signed to unsigned comparison here.
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP
On Thursday 28 August 2014 17:30:17 Alan Cox wrote:
> On 08/28/2014 16:15, Matthew D. Fuller wrote:
> > On Thu, Aug 28, 2014 at 10:11:39PM +0100 I heard the voice of
> >
> > Steven Hartland, and lo! it spake thus:
> >> Its very likely applicable to stable/9 although I've never used 9
> >> myself,
On Thu, Aug 28, 2014 at 10:11:39PM +0100, Steven Hartland wrote:
> I'll MFC to 9 and possibly 8 as well at that time if relavent.
Although I don't use ZFS on stable/8, your care about our best stable
branch :) is much appreciated.
./danfe
___
svn-src-he
On Thursday 28 August 2014 17:30:17 Alan Cox wrote:
> On 08/28/2014 16:15, Matthew D. Fuller wrote:
> > On Thu, Aug 28, 2014 at 10:11:39PM +0100 I heard the voice of
> >
> > Steven Hartland, and lo! it spake thus:
> >> Its very likely applicable to stable/9 although I've never used 9
> >> myself,
On 08/28/2014 16:15, Matthew D. Fuller wrote:
> On Thu, Aug 28, 2014 at 10:11:39PM +0100 I heard the voice of
> Steven Hartland, and lo! it spake thus:
>> Its very likely applicable to stable/9 although I've never used 9
>> myself, we jumped from 9 direct to 10.
> This is actually hitting two diffe
On Thu, 28 Aug 2014, Steven Hartland wrote:
> > Thank you, and also Karl and Devin for this work!
> >
> > Is this change applicable to stable/9? I suppose, pretty large base of users
> > could benefit from this.
>
> Its very likely applicable to stable/9 although I've never used 9 myself,
> we j
On Thu, Aug 28, 2014 at 10:11:39PM +0100 I heard the voice of
Steven Hartland, and lo! it spake thus:
>
> Its very likely applicable to stable/9 although I've never used 9
> myself, we jumped from 9 direct to 10.
This is actually hitting two different issues from the two bugs:
- 191510 is about
- Original Message -
From: "Dmitry Morozovsky"
Steve,
On Thu, 28 Aug 2014, Steven Hartland wrote:
Author: smh
Date: Thu Aug 28 19:50:08 2014
New Revision: 270759
URL: http://svnweb.freebsd.org/changeset/base/270759
Log:
Refactor ZFS ARC reclaim logic to be more VM cooperative
Steve,
On Thu, 28 Aug 2014, Steven Hartland wrote:
> Author: smh
> Date: Thu Aug 28 19:50:08 2014
> New Revision: 270759
> URL: http://svnweb.freebsd.org/changeset/base/270759
>
> Log:
> Refactor ZFS ARC reclaim logic to be more VM cooperative
[snip]
> Credit to Karl Denninger for the orig
Author: smh
Date: Thu Aug 28 19:50:08 2014
New Revision: 270759
URL: http://svnweb.freebsd.org/changeset/base/270759
Log:
Refactor ZFS ARC reclaim logic to be more VM cooperative
Prior to this change we triggered ARC reclaim when kmem usage passed 3/4
of the total available, as indicated
52 matches
Mail list logo
