search for: reclaiming

...CONTRACT, STRICT LIABILITY, + * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT + * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#ifndef NBDKIT_RECLAIM_H +#define NBDKIT_RECLAIM_H + +#include "bitmap.h" + +/* Do we support reclaiming cache blocks? */ +#ifdef FALLOC_FL_PUNCH_HOLE +#define HAVE_CACHE_RECLAIM 1 +#else +#undef HAVE_CACHE_RECLAIM +#endif + +extern void reclaim (int fd, struct bitmap *bm); + +#endif /* NBDKIT_RECLAIM_H */ diff --git a/filters/cache/blk.c b/filters/cache/blk.c index b256446..028eedb 100644 --- a/filte...

...threshold>. +Once the size is below the low threshold, no more reclaim work is done +until the size exceeds the high threshold again. + +The default thresholds are high 95% and low 80%. The thresholds are +expressed as percentages of C<cache-max-size>, and may be greater than +100. + +The reclaiming work discards blocks from the cache in the following +order of priority: + +=over 4 + +=item * + +(Highest priority / first to be reclaimed.) +Least recently used clean blocks are discarded from the cache. + +=item * + +Least recently used dirty blocks are flushed to the plugin and +discarded. + +=...

...be greater than > +100. Do the thresholds support fractional percentages, like 90.5, or must they be integral? Should we enforce that low threshold < high threshold? What does it really mean to have a threshold > 100 - that we can never reach the high threshold? > +/* Do we support reclaiming cache blocks? */ > +#ifdef FALLOC_FL_PUNCH_HOLE > +#define HAVE_CACHE_RECLAIM 1 > +#else > +#undef HAVE_CACHE_RECLAIM > +#endif > + Should the man page mention that max cache size can only be enforced with kernel support? Do we want to go further and probe whether FALLOC_FL_PUNC...

...threshold>. +Once the size is below the low threshold, no more reclaim work is done +until the size exceeds the high threshold again. + +The default thresholds are high 95% and low 80%. The thresholds are +expressed as percentages of C<cache-max-size>, and may be greater than +100. + +The reclaiming work discards blocks from the cache in the following +order of priority: + +=over 4 + +=item * + +(Highest priority / first to be reclaimed.) +Least recently used clean blocks are discarded from the cache. + +=item * + +Least recently used dirty blocks are flushed to the plugin and +discarded. + +=...

...sparse files, which @@ -48,7 +50,18 @@ extern enum cache_mode { CACHE_MODE_UNSAFE, } cache_mode; +/* Maximum size of the cache and high/low thresholds. */ +extern int64_t max_size; +extern int hi_thresh, lo_thresh; + /* Cache read requests. */ extern bool cache_on_read; +/* Do we support reclaiming cache blocks? */ +#ifdef FALLOC_FL_PUNCH_HOLE +#define HAVE_CACHE_RECLAIM 1 +#else +#undef HAVE_CACHE_RECLAIM +#endif + #endif /* NBDKIT_CACHE_H */ diff --git a/filters/cache/blk.c b/filters/cache/blk.c index b256446..294f0cb 100644 --- a/filters/cache/blk.c +++ b/filters/cache/blk.c @@ -46,6 +46,...

...CONTRACT, STRICT LIABILITY, + * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT + * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#ifndef NBDKIT_RECLAIM_H +#define NBDKIT_RECLAIM_H + +#include "bitmap.h" + +/* Do we support reclaiming cache blocks? */ +#ifdef FALLOC_FL_PUNCH_HOLE +#define HAVE_CACHE_RECLAIM 1 +#else +#undef HAVE_CACHE_RECLAIM +#endif + +/* Check if we need to reclaim blocks, and if so reclaim up to two + * blocks. + * + * Note this must be called with the blk lock held. + */ +extern void reclaim (int fd, struct...

v3 was broken by a bad rebase, so let's forget about that one. Compared to v2: - Patch 1 is the same except for a minor comment change. - Patch 2 splits the reclaim code into a separate file (filters/cache/reclaim.c) - Addressed Eric's comments from his review of v2. - Retested on Linux and FreeBSD.

...ching a NIC (or individual Rx rings on the NIC) to polling mode. The receive interrupt will become not only rarer, but more importantly outside the control of the NIC drivers. Some drivers, on the other hand, were designed and written before that change. They used to piggy-back the tx descriptor reclaiming at the end of the Rx interrupt for example. At the same time, they disable to transmit interrupt all together, in an effort to minimize the number of interrupts to the host (and the entailed context switches). As expected, that sort of approach will (and it was actually observed) lead to quick...

...te() calls; but a different test that is truly random-access will be dirtying enough sub-hole regions that you can't reclaim anything? Or do you need the cache module to use a larger block size by default, or even add a parameter to control the block size? > + > +/* If we are currently reclaiming blocks from the cache. > + * > + * The state machine starts in the NOT_RECLAIMING state. When the > + * size of the cache exceeds the high threshold, we move to > + * RECLAIMING_LRU. Once we have exhausted all LRU blocks, we move to > + * RECLAIMING_ANY (reclaiming any blocks). &gt...

Patch 1 is the same as last time, except for a minor comment fix. Patch 2 should address everything that Eric mentioned in his review, and has been retested. Rich.

I'm getting constantly high numbers of page reclaims & involuntary context switches for dovecot/auth. page reclaims = minor faults = cpu switching back to system-mode, But why is the auth process doing that so excessively? Same for the large number of involuntary context switches... Attached is my "dovecot -n" output. Date: Sun, 07 Nov 2010 20:40:34 +0100 type real

These are essentially identical to what was previously posted as patches 6/9 through 9/9 here: https://www.redhat.com/archives/libguestfs/2018-December/msg00145.html except that it has been rebased onto the current git master and retested thoroughly. Rich.

On 15 Dec 2016, at 07:26, haifeng.qin at wellintech.com via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > For help: > > for loop lead to stack overflow, want to actively reclaim stack memory of alloc instruction. > > How to actively reclaim stack memory ? This sounds as if you’re putting the alloca inside the loop, not in the entry basic block and reusing it. If you

Gents, We want to understand the mechanism of zfs a bit better. Q: what is the design/algorithm of zfs in terms of reclaiming unused blocks? Q: what criteria is there for zfs to start reclaiming blocks Issue at hand is an LDOM or zone running in a virtual (thin-provisioned) disk on a NFS server and a zpool inside that vdisk. This vdisk tends to grow in size even if the user writes and deletes a file again. Question is,...

v4: https://www.redhat.com/archives/libguestfs/2019-January/msg00032.html v5: - Now we set the block size at run time. I'd like to say that I was able to test this change, but unfortunately I couldn't find any easy way to create a filesystem on x86-64 with a block size > 4K. Ext4 doesn't support it at all, and XFS doesn't support block size > page size (and I

On Thu 12-07-18 19:34:16, Wei Wang wrote: > On 07/12/2018 04:13 PM, Michal Hocko wrote: > > On Thu 12-07-18 10:52:08, Wei Wang wrote: > > > On 07/12/2018 10:30 AM, Linus Torvalds wrote: > > > > On Wed, Jul 11, 2018 at 7:17 PM Wei Wang <wei.w.wang at intel.com> wrote: > > > > > Would it be better to remove __GFP_THISNODE? We actually want to get

...; memory by shrinking the balloon, and then the driver adds the > memory back to the balloon. Basically a busy no-op." > > The name "deflate on OOM" makes it pretty clear when deflation should > happen - after other approaches to reclaim memory failed, not while > reclaiming. This allows to minimize the footprint of a guest - memory > will only be taken out of the balloon when really needed. > > Especially, a drop_slab() will result in the whole balloon getting > deflated - undesired. Could you explain why some more? drop_caches shouldn't be really us...

...; memory by shrinking the balloon, and then the driver adds the > memory back to the balloon. Basically a busy no-op." > > The name "deflate on OOM" makes it pretty clear when deflation should > happen - after other approaches to reclaim memory failed, not while > reclaiming. This allows to minimize the footprint of a guest - memory > will only be taken out of the balloon when really needed. > > Especially, a drop_slab() will result in the whole balloon getting > deflated - undesired. Could you explain why some more? drop_caches shouldn't be really us...

For help: for loop lead to stack overflow, want to actively reclaim stack memory of alloc instruction. How to actively reclaim stack memory ? haifeng.qin at wellintech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161215/54b3b18c/attachment.html>

-> Is there a way to get a date stamp for the dmesg? At least on CentOS7: dmesg -T ----- Original Message ----- From: "Dan Hyatt" <dhyatt at dsgmail.wustl.edu> To: "CentOS mailing list" <centos at centos.org> Sent: Tuesday, October 18, 2016 1:36:46 PM Subject: [CentOS] Lockd: failed to reclaim lock for pid ... My environment is "heterogeneous" my