Project

General

Profile

Actions

Feature #13834

closed

want extensible page_resv

Added by Patrick Mooney over 2 years ago. Updated about 2 years ago.

Status:
Closed
Priority:
Normal
Category:
kernel
Start date:
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:
External Bug:

Description

Memory consumers such as segkmem and bhyve require pages which remain locked during the duration of the allocation. To ensure adequate pages are available prior to embarking on such a task, they currently use page_resv, which ensures that an adequate number of pages is set aside. This interface falls short in how it handles conditions when there are not enough free pages. If KM_SLEEP is specified, page_resv will conditionally sleep while waiting for reap activity to free up enough pages. If KM_NOSLEEP is passed instead, none of the memory pressure mechanisms employed in the KM_SLEEP case are used, and the page_resv call reports failure (provided that not enough free pages exist at the time). I propose adding page_xresv which calls into a provided wait_cb function when reaping for a KM_SLEEP reservation has begun. This will allow the caller to heed signals and potentially bail out of such an attempt if they decide that the wait for free pages has gone on too long.

Actions #1

Updated by Electric Monk over 2 years ago

  • Gerrit CR set to 1522
Actions #2

Updated by Patrick Mooney about 2 years ago

Being that #13833 was the driver behind this addition, it was the primary test case. Normal page_(x)resv operations will succeed immediately if there is adequate availrmem to fulfill the request. In order to test the delay callback functionality, I first put the system under moderate memory pressure by expanding the vmm reservoir. Once free memory was fairly constrained, I then issued another request to expand the reservoir - one which was larger than the current pool of freemem. All the while, I was tracing the return value of vmmr_resv_wait calls. After issuing the reservoir expand request, I immediately canceled it with SIGINT. The results those actions were a 0 value return from vmmr_resv_wait which indicated that the page_xresv operation should be cancelled. The vmmr_add operation clearly showed the operation failing, as the reservoir remained the same size as before the attempted addition. A timely response to the SIGINT is evidence that page_xresv was paying heed to the results of the wait callback.

Actions #3

Updated by Electric Monk about 2 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 0 to 100

git commit b57f5d3e6a2df8d435e606797cf3934811848343

commit  b57f5d3e6a2df8d435e606797cf3934811848343
Author: Patrick Mooney <pmooney@pfmooney.com>
Date:   2021-07-27T19:26:22.000Z

    13833 want bhyve memory reservoir
    13822 bhyve memory should exert memory pressure
    13834 want extensible page_resv
    13821 vmmctl ioctls should have more structure
    Reviewed by: Andy Fiddaman <andy@omnios.org>
    Reviewed by: Jason King <jason.brian.king@gmail.com>
    Reviewed by: Dan Cross <cross@oxidecomputer.com>
    Reviewed by: Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org>
    Reviewed by: Mike Zeller <mike.zeller@joyent.com>
    Approved by: Dan McDonald <danmcd@joyent.com>

Actions

Also available in: Atom PDF