<p>There is a modestly obscure means to attach *_DONTNEED (to achieve kernel delayed writes and removing pages when I/O is complete) using the existing rpm.org rpmfiArchiveReadToFilePsm() Fwrite->write(3) loop calling setvbuf(3) immediately after Fopen on the fopencookie(3) FILE *.</p>
<p>(aside)<br>
Personally, I think mmap(2) and madvise(2) are easier to implement/maintain than rpmio fopencookie(3) wrapped stdio(3) abstractions like setvbuf(3): YMMV.</p>
<p>The idea behind *_DONTNEED -- to minimize competition for scarce resources -- is to hint to the kernel that RPM write buffers (actually pages) can be reused by other processes as soon as written to disk, rather than cached. RPM package installation is always fire-and-forget for package files, not true in general for file writes.</p>
<p>Letting the kernel manage its own resources as necessary may be sufficient to prevent database stalling/starvation as an alternative to attempting explicit fsync(3) invalidation of cached I/O buffers<br>
which has the unfortunate side effect of blocking RPM until the fsync(3) system call returns.</p>
<p>(aside)<br>
This <em>IS</em> what used to be in RPM, and was a significant win at the time (but also included directly uncompressing into the mmap(2) buffer avoiding a copy, and increasing the zlib buffer size from 32K -> 256K, which has long since been upstreamed). Someone else will have to speak to why mmap(2) was ripped out at rpm.org.</p>
<p>(hth, off to bed)</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/rpm-software-management/rpm/pull/187#issuecomment-291795090">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ANb80-MNACtGeFunrIJHMnj9k5-oH6SQks5rs1SxgaJpZM4MyLOi">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/ANb80zkd8n3j9WrKYGThbejln2O-sreqks5rs1SxgaJpZM4MyLOi.gif" width="1" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  <link itemprop="url" href="https://github.com/rpm-software-management/rpm/pull/187#issuecomment-291795090"></link>
  <meta itemprop="name" content="View Pull Request"></meta>
</div>
<meta itemprop="description" content="View this Pull Request on GitHub"></meta>
</div>

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/rpm-software-management/rpm","title":"rpm-software-management/rpm","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/rpm-software-management/rpm"}},"updates":{"snippets":[{"icon":"PERSON","message":"@n3npq in #187: There is a modestly obscure means to attach *_DONTNEED (to achieve kernel delayed writes and removing pages when I/O is complete) using the existing rpm.org rpmfiArchiveReadToFilePsm() Fwrite-\u003ewrite(3) loop calling setvbuf(3) immediately after Fopen on the fopencookie(3) FILE *.\r\n\r\n(aside)\r\nPersonally, I think mmap(2) and madvise(2) are easier to implement/maintain than rpmio fopencookie(3) wrapped stdio(3) abstractions like setvbuf(3): YMMV.\r\n\r\nThe idea behind *_DONTNEED -- to minimize competition for scarce resources -- is to hint to the kernel that RPM write buffers (actually pages) can be reused by other processes as soon as written to disk, rather than cached. RPM package installation is always fire-and-forget for package files, not true in general for file writes.\r\n\r\nLetting the kernel manage its own resources as necessary may be sufficient to prevent database stalling/starvation as an alternative to attempting explicit fsync(3) invalidation of cached I/O buffers\r\nwhich has the unfortunate side effect of blocking RPM until the fsync(3) system call returns.\r\n\r\n(aside)\r\nThis *IS* what used to be in RPM, and was a significant win at the time (but also included directly uncompressing into the mmap(2) buffer avoiding a copy, and increasing the zlib buffer size from 32K -\u003e 256K, which has long since been upstreamed). Someone else will have to speak to why mmap(2) was ripped out at rpm.org.\r\n\r\n(hth, off to bed)"}],"action":{"name":"View Pull Request","url":"https://github.com/rpm-software-management/rpm/pull/187#issuecomment-291795090"}}}</script>