show jtree <> memory extensive help

This document provides explanation for the various field of show jtree <> memory extensive command

What do the different values in show jtree <> memory extensive mean ?

The hidden keyword “help” for this command explains the different fields of this output

Example :
ADPC3(leffe-re0 vty)# sho jtree 0 memory extensive help

Bytes available from free pages:
Memory present in entire free pages, as opposed to space present in partially allocated pages

Wasted:
Space wasted because requested allocations are not a multiple of page size

Unusable:
Small allocations are satisfied by carving a page into fixed size chunks. Unsuable is the memory wasted because
the chunk size does not divide the page size evenly.

Pages used in page alloc:
Number of pages allocated because the application request was in multiple of pages

Partially Used:
Sum total of pages that are divided in chunks, and only some chunks have been allocated

Partial Filled Pages:
Lists of pages from which small sized allocations are satisfied. Multiple chunk sizes have been chosen to satisfy all sorts of allocations. Each line displays the details for a given chunk size. The overhead column is the space wasted in this size

Free Page Lists:
Lists of pages from which larger sized allocations are satisfied. There are multiple buckets, depending on the number of of pages in each request

Fragmentation Index:
Calculated as = 1 – (biggest_free_blk/total_avail_mem)

Misc. Counters:
Releases Number of times callers have requested that memory be made available to the free pool immediately as
opposed to first insert it in a pending list Pending Number of frees that are pending, as entries cannot be released to the free pool, because there could be some key engines processing those memories

Pending Forced
Number of entries forced off the pending list in order to make room for new free requests

Free Blocked
Some times a memory free request is blocked to wait for clearing out some entries in the pending list. This count records the number of such occurrences.

Sync Writes
During ISSU the allocator state is synced to the srams in one go. Count the number of writes we issued to get
an idea of the time taken.

About the author

James Palmer

Leave a Comment