initially, just a couple--but the strategizing step forces an internal
api to develop.
Matt
On Fri, Aug 11, 2017 at 8:49 AM, Daniel Gryniewicz <d...@redhat.com> wrote:
> That seems overkill to me. How many strategies would we support (and test)?
>
> Part of the problem is that we've drastically changed how FDs are handled.
> We need to rethink how LRU should work in that context, I think.
>
> Daniel
>
>
> On 08/10/2017 07:59 PM, Matt Benjamin wrote:
>>
>> I think the particular thresholds of opens and inode count are
>> interacting in a way we'd like to change. I think it might make sense
>> to delegate the various decision points to maybe a vector of strategy
>> functions, letting more varied approaches compete?
>>
>> Matt
>>
>> On Thu, Aug 10, 2017 at 7:12 PM, Pradeep <pradeep.tho...@gmail.com> wrote:
>>>
>>> Debugged this a little more. It appears that the entries that can be
>>> reaped
>>> are not at the LRU position (head) of the L1 queue. So those can be
>>> free'd
>>> later by lru_run(). I don't see it happening either for some reason.
>>>
>>> (gdb) p LRU[1].L1
>>> $29 = {q = {next = 0x7fb459e71960, prev = 0x7fb3ec3c0d30}, id =
>>> LRU_ENTRY_L1, size = 260379}
>>>
>>> head of the list is an entry with refcnt 2; but there are several entries
>>> with refcnt 1.
>>>
>>> (gdb) p *(mdcache_lru_t *)0x7fb459e71960
>>> $30 = {q = {next = 0x7fb43ddea8a0, prev = 0x7d68a0 <LRU+224>}, qid =
>>> LRU_ENTRY_L1, refcnt = 2, flags = 0, lane = 1, cf = 2}
>>> (gdb) p *(mdcache_lru_t *)0x7fb43ddea8a0
>>> $31 = {q = {next = 0x7fb3f041f9a0, prev = 0x7fb459e71960}, qid =
>>> LRU_ENTRY_L1, refcnt = 1, flags = 0, lane = 1, cf = 0}
>>> (gdb) p *(mdcache_lru_t *)0x7fb3f041f9a0
>>> $32 = {q = {next = 0x7fb466960200, prev = 0x7fb43ddea8a0}, qid =
>>> LRU_ENTRY_L1, refcnt = 1, flags = 0, lane = 1, cf = 0}
>>> (gdb) p *(mdcache_lru_t *)0x7fb466960200
>>> $33 = {q = {next = 0x7fb451e20570, prev = 0x7fb3f041f9a0}, qid =
>>> LRU_ENTRY_L1, refcnt = 2, flags = 0, lane = 1, cf = 1}
>>>
>>> The entries with refcnt 1 are moved to L2 by the background thread
>>> (lru_run). However it does it only of the open file count is greater than
>>> low water mark. In my case, the open_fd_count is not high; so lru_run()
>>> doesn't call lru_run_lane() to demote those entries to L2. What is the
>>> best
>>> approach to handle this scenario?
>>>
>>> Thanks,
>>> Pradeep
>>>
>>>
>>>
>>> On Mon, Aug 7, 2017 at 6:08 AM, Daniel Gryniewicz <d...@redhat.com>
>>> wrote:
>>>>
>>>>
>>>> It never has been. In cache_inode, a pin-ref kept it from being
>>>> reaped, now any ref beyond 1 keeps it.
>>>>
>>>> On Fri, Aug 4, 2017 at 1:31 PM, Frank Filz <ffilz...@mindspring.com>
>>>> wrote:
>>>>>>
>>>>>> I'm hitting a case where mdcache keeps growing well beyond the high
>>>>>> water
>>>>>> mark. Here is a snapshot of the lru_state:
>>>>>>
>>>>>> 1 = {entries_hiwat = 100000, entries_used = 2306063, chunks_hiwat =
>>>>>
>>>>> 100000,
>>>>>>
>>>>>> chunks_used = 16462,
>>>>>>
>>>>>> It has grown to 2.3 million entries and each entry is ~1.6K.
>>>>>>
>>>>>> I looked at the first entry in lane 0, L1 queue:
>>>>>>
>>>>>> (gdb) p LRU[0].L1
>>>>>> $9 = {q = {next = 0x7fad64256f00, prev = 0x7faf21a1bc00}, id =
>>>>>> LRU_ENTRY_L1, size = 254628}
>>>>>> (gdb) p (mdcache_entry_t *)(0x7fad64256f00-1024)
>>>>>> $10 = (mdcache_entry_t *) 0x7fad64256b00
>>>>>> (gdb) p $10->lru
>>>>>> $11 = {q = {next = 0x7fad65ea0f00, prev = 0x7d67c0 <LRU>}, qid =
>>>>>> LRU_ENTRY_L1, refcnt = 2, flags = 0, lane = 0, cf = 0}
>>>>>> (gdb) p $10->fh_hk.inavl
>>>>>> $13 = true
>>>>>
>>>>>
>>>>> The refcount 2 prevents reaping.
>>>>>
>>>>> There could be a refcount leak.
>>>>>
>>>>> Hmm, though, I thought the entries_hwmark was a hard limit, guess
>>>>> not...
>>>>>
>>>>> Frank
>>>>>
>>>>>> Lane 1:
>>>>>> (gdb) p LRU[1].L1
>>>>>> $18 = {q = {next = 0x7fad625c0300, prev = 0x7faec08c5100}, id =
>>>>>> LRU_ENTRY_L1, size = 253006}
>>>>>> (gdb) p (mdcache_entry_t *)(0x7fad625c0300 - 1024)
>>>>>> $21 = (mdcache_entry_t *) 0x7fad625bff00
>>>>>> (gdb) p $21->lru
>>>>>> $22 = {q = {next = 0x7fad66fce600, prev = 0x7d68a0 <LRU+224>}, qid =
>>>>>> LRU_ENTRY_L1, refcnt = 2, flags = 0, lane = 1, cf = 1}
>>>>>>
>>>>>> (gdb) p $21->fh_hk.inavl
>>>>>> $24 = true
>>>>>>
>>>>>> As per LRU_ENTRY_RECLAIMABLE(), these entry should be reclaimable. Not
>>>>>> sure why it is not able to claim it. Any ideas?
>>>>>>
>>>>>> Thanks,
>>>>>> Pradeep
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ----------------------------------------------------------------------------
>>>>> --
>>>>>>
>>>>>> Check out the vibrant tech community on one of the world's most
>>>>>> engaging
>>>>>> tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>>> _______________________________________________
>>>>>> Nfs-ganesha-devel mailing list
>>>>>> Nfs-ganesha-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>>>>>
>>>>>
>>>>>
>>>>> ---
>>>>> This email has been checked for viruses by Avast antivirus software.
>>>>> https://www.avast.com/antivirus
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Check out the vibrant tech community on one of the world's most
>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>> _______________________________________________
>>>>> Nfs-ganesha-devel mailing list
>>>>> Nfs-ganesha-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Nfs-ganesha-devel mailing list
>>> Nfs-ganesha-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>>>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
