LU-18086 obdclass: page_pools shrinker fix

LU-18086 obdclass: page_pools shrinker fix

page_pool shrinker should consider opp_free_pages
as a number of memory regions with the size of
2^pool_order pages. Otherwise it starts shrinking
only when becomes too large, for example 2GB instead
of 64MB. It often might be the reason of OOM especially
when compressed files with different chunk-sizes
have been written. In a such case several pools
created for different chunk sizes might hold gigabytes
of memory without any chance to release it.

Fix element_size to return correct element size instead
of number of pages. Because of that elements in
page_pools had below sizes:

  order 0 = 4096
  order 1 = 2
  order 2 = 4
  ....
  order 17 = 131072

This made possible to have elements with sizes 2,4,8,...
bytes that have been allocated with OBD_VMALLOC.
Now all sizes are miltiple of PAGE_SIZE:

  order 0 = 4096
  order 1 = 8192
  ...
  order 5 = 131072

Change the logic around opp_idle_idx.

1. Recalculate opp_idle_idx in __sptlrpc_pool_put_pages the
   same way as it done in __sptlrpc_pool_get_pages. It is
   possible that opp_idle_idx might become 0 or very small
   (less than 10). If there is no new allocations it would
   be impossible to free anything from the pool during 40
   seconds(CACHE_QUIESCENT_PERIOD) despite the large amount
   of free elements ready to shrinking.
2. In pool_shrink_count when opp_idle_idx == IDLE_IDX_MAX,
   it means no one accessed pool for CACHE_QUIESCENT_PERIOD
   (40 seconds), i.e. we may release as much as possible
   pages. Earlier in a such case pool_shrink_count always
   returned 0. Another words it was impossible to shrink
   anything from the pool if there was no allocations for 40s.

Signed-off-by: Sergey Cheremencev <scherementsev@ddn.com>
Signed-off-by: Artem Blagodarenko <ablagodarenko@ddn.com>
Change-Id: I6b55ba67b0d21cdffdb57034e8e66063745f796e
Reviewed-on: https://review.whamcloud.com/c/fs/lustre-release/+/55914
Tested-by: jenkins <devops@whamcloud.com>
Tested-by: Maloo <maloo@whamcloud.com>
Reviewed-by: Andreas Dilger <adilger@whamcloud.com>
Reviewed-by: Oleg Drokin <green@whamcloud.com>