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

Reply via email to