<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel">
    <title>gmane.os.netbsd.devel.kernel</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.devel.kernel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44150"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44149"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44148"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44147"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44146"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44145"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44144"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44143"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44142"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44141"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44140"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44139"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44137"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44136"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44134"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44133"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44132"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44128"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44127"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44126"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44150">
    <title>Re: 4.0.1 i386 wedged</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44150</link>
    <description>&lt;pre&gt;
Oh, it worked for me too - for a while.  It didn't wedge until, I
suspect, the system came under memory pressure.  If I'd written an
amount that's small compared to available RAM before flushing and
unmounting, I very well might not have noticed any problem at all.

Also, your use case was read-mostly, sounds like.  Mine was not.

/~\ The ASCII  Mouse
\ / Ribbon Campaign
 X  Against HTMLmouse&amp;lt; at &amp;gt;rodents-montreal.org
/ \ Email!     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

&lt;/pre&gt;</description>
    <dc:creator>der Mouse</dc:creator>
    <dc:date>2013-05-22T13:21:25</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44149">
    <title>Re: Thinking about NCQ support for NetBSD</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44149</link>
    <description>&lt;pre&gt;
Yeah, you need something with more than just wdc(4)/pciide(4)-style
registers.  ahcisata(4), siisata(4), and mvsata(4) would be capable of
NCQ.


The first issue is the ata(4) layer, which doesn't currently support
multiple outstanding commands per drive.  What little work I did on it
I probably swept away, as nothing useful came of it last I tried.

Jonathan Kollasch

&lt;/pre&gt;</description>
    <dc:creator>Jonathan A. Kollasch</dc:creator>
    <dc:date>2013-05-22T12:42:50</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44148">
    <title>Re: Thinking about NCQ support for NetBSD</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44148</link>
    <description>&lt;pre&gt;
Support on the controller side is needed AFAIK. controllers exposing
only the pciide registers probably can't support NCQ at all.
For NCQ to be used in an efficient way, a smart controller is probably
requireed.



AFAIK no. 

&lt;/pre&gt;</description>
    <dc:creator>Manuel Bouyer</dc:creator>
    <dc:date>2013-05-22T11:32:42</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44147">
    <title>Re: 4.0.1 i386 wedged</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44147</link>
    <description>&lt;pre&gt;
It _used_ to work - in recent years I did a recovery of a linux lvm
backup by nfs mounting the storage that had the file created by
dd'ing the linux disk, doing a vnconfig and then a lvm change to get at
the linux file systems.

&lt;/pre&gt;</description>
    <dc:creator>Brett Lymn</dc:creator>
    <dc:date>2013-05-22T06:54:12</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44146">
    <title>Thinking about NCQ support for NetBSD</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44146</link>
    <description>&lt;pre&gt;hello.  Recently I've been working on some fixes for the mpt(4)
driver.  In the process of getting those fixes working, I began thinking
about how hard it would be to get NCQ tag queueing working for NetBSD.  In
the process of getting my head around what is involved, I find I have
questions.  If someone wants to share what they know here or privately,
I'd be interested in reading.

1.  I read a document that discussed ahcisata and its advantages over
traditional IDE mode.  One of the advantages it touted was that ahcisata
would support NCQ tag queueing.  Is it a requirement in order for NCQ
tag queueing to work that the interface card support it as well?  For
example, the viaide(4) driver supports SATA controllers, but says nothing
about NCQ support or the potential for it.

2.  Does anyone have any preliminary patches for NCQ support that the never
got into the system?

-thanks
-Brian

&lt;/pre&gt;</description>
    <dc:creator>Brian Buhrow</dc:creator>
    <dc:date>2013-05-22T06:14:03</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44145">
    <title>Re: 4.0.1 i386 wedged</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44145</link>
    <description>&lt;pre&gt;
Okay.  I juggled things around a bit, so the vnconfig and mount were
done on the NFS server instead, with the vnd mount point exported.
Then, while adding debugging code to the stuff running on the NFS
client, I found that I no longer needed to do it at all. :-)

So it's not a practical issue for me now.  It might turn into one at
some as-yet-indeterminate future point, but I'll deal with that
if-and-when it happens.

Thanks for the note!

/~\ The ASCII  Mouse
\ / Ribbon Campaign
 X  Against HTMLmouse&amp;lt; at &amp;gt;rodents-montreal.org
/ \ Email!     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

&lt;/pre&gt;</description>
    <dc:creator>der Mouse</dc:creator>
    <dc:date>2013-05-21T20:11:27</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44144">
    <title>Re: 4.0.1 i386 wedged</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44144</link>
    <description>&lt;pre&gt;hello.  I was under the impression that vnconfigging an nfs-mounted
file continues to not work to today -- and that is why xen has such a hard
time supporting guests under NFS.  In other words, "Don't do that".  If you
need such a big file  vnconfigged, use local disk.
I could be wrong on this, but I'm pretty sure I have it right.

-Brian

On May 21,  2:43pm, der Mouse wrote:
} Subject: 4.0.1 i386 wedged
} I don't know if anyone recalls enough 4.x to say anything useful here,
} but if anyone does and cares to comment....
} 
} The machine: 4.0.1 i386.  Two CPUs.  (Kernel has MULTIPROCESSOR,
} MPBIOS, and APM_NO_IDLE turned on.)
} 
} NFS-mount a filesystem with a big (half-terabyte) file in it.  vnconfig
} that onto vnd0.  Mount /dev/vnd0d.  Write stuff to it.
} 
} Machine locks up.  Responsive to ping, but userland is totally wedged,
} doesn't even respond to RETURN on the console.  Break into ddb and do
} ps and find pagedaemon is waiting on emergva.  It appears to be
} deadlocked against itself; my impres&lt;/pre&gt;</description>
    <dc:creator>Brian Buhrow</dc:creator>
    <dc:date>2013-05-21T19:25:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44143">
    <title>4.0.1 i386 wedged</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44143</link>
    <description>&lt;pre&gt;I don't know if anyone recalls enough 4.x to say anything useful here,
but if anyone does and cares to comment....

The machine: 4.0.1 i386.  Two CPUs.  (Kernel has MULTIPROCESSOR,
MPBIOS, and APM_NO_IDLE turned on.)

NFS-mount a filesystem with a big (half-terabyte) file in it.  vnconfig
that onto vnd0.  Mount /dev/vnd0d.  Write stuff to it.

Machine locks up.  Responsive to ping, but userland is totally wedged,
doesn't even respond to RETURN on the console.  Break into ddb and do
ps and find pagedaemon is waiting on emergva.  It appears to be
deadlocked against itself; my impression from the stack trace is that
it's trying to page something out and finds itself wanting to page
something in to do so.

Is this a case of "don't do that, then", or should this work and I just
need to track down a bug?

/~\ The ASCII  Mouse
\ / Ribbon Campaign
 X  Against HTMLmouse&amp;lt; at &amp;gt;rodents-montreal.org
/ \ Email!     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

&lt;/pre&gt;</description>
    <dc:creator>der Mouse</dc:creator>
    <dc:date>2013-05-21T18:43:44</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44142">
    <title>Re: NetBSD/avr32</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44142</link>
    <description>&lt;pre&gt;
Yes. We are using a NGW-100. We'd like to work on a STK-1000 as well,
but unfortunately they've been discontinued, and can't find any on
ebay.

-Tomas.

&lt;/pre&gt;</description>
    <dc:creator>Tomas Niño Kehoe</dc:creator>
    <dc:date>2013-05-19T02:27:12</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44141">
    <title>Re: NetBSD/avr32</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44141</link>
    <description>&lt;pre&gt;

Nice!


Is this this the same SoC that is used in NGW-100?

-uwe

&lt;/pre&gt;</description>
    <dc:creator>Valery Ushakov</dc:creator>
    <dc:date>2013-05-18T19:45:31</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44140">
    <title>Re: NetBSD/avr32</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44140</link>
    <description>&lt;pre&gt;In article &amp;lt;CAEv1cWcb1-+eyU+enmDQ9oMH8tZUanu8k4sPUrXW8uVpwfAXzA&amp;lt; at &amp;gt;mail.gmail.com&amp;gt;,
Tomas Niño Kehoe  &amp;lt;tomasninokehoe&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:

Looks like you've made a lot of progress. You might be interested in looking
at https://wiki.freebsd.org/FreeBSD/avr32

christos


&lt;/pre&gt;</description>
    <dc:creator>Christos Zoulas</dc:creator>
    <dc:date>2013-05-18T17:44:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44139">
    <title>NetBSD/avr32</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44139</link>
    <description>&lt;pre&gt;Hi all,

I'd like to announce the existence of a NetBSD port to the AVR32 processor
architecture.
This port is being developed in the context of my engineering thesis at the
University of Buenos Aires, Argentina. It is directed by Leandro Santi.

This is my first experience with AVR32. My previous experience with RISC
architectures involves MIPS. Consecuently, the MIPS port was taken as a
staring point into NetBSD. Some parts of the MD code contain MIPS code
snippets -guarded by #ifdef notyet clauses- acting as a
reference. These will be removed in the near future. Multiple MIPS
implementations were studied to be
able to understand the interaction between Machine Dependent code (MD) and
Machine independent code (MI).

The milestone that will mark the end of this thesis is the execution of a
static 32-bit Linux binary, read from an in-memory file system supported by
md.c. Currently, the system is able to mount the filesystem successfully,
yet system call support and Linux compatibilty are currently under
deve&lt;/pre&gt;</description>
    <dc:creator>Tomas Niño Kehoe</dc:creator>
    <dc:date>2013-05-18T04:58:36</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44137">
    <title>Re: [GSoC 2013] Implement file system flags to scrub data blocks before deletion</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44137</link>
    <description>&lt;pre&gt;
This strikes me as a bad idea.  One of the major problems with our LFS
implementation is that it's almost impossible to keep the kernel and the
cleaner in sync while avoiding deadlock.

Another, of course, is the difficulty of maintaining our security model
while allowing the cleaner to access raw blocks, even with the bmap/mark
interface the cleaner uses.  It seems to me the kernel would have to do
the cleaning -- which would be easier today than it was for the LFS
code because we have better ways to defer activity in the kernel.

Thor

&lt;/pre&gt;</description>
    <dc:creator>Thor Lancelot Simon</dc:creator>
    <dc:date>2013-05-17T12:19:55</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44136">
    <title>Re: [GSoC 2013] Implement file system flags to scrub data blocks before deletion</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44136</link>
    <description>&lt;pre&gt;

- Better start implementing mount flag and file flags and integrate
  them into mount_xxx, libutil and chflags first.

- Kauth integration is missing.  I propose to integrate with kauth so
  it becomes possible to set 'scrub_on_delete' per-file with flags,
  per-mount with flag and per-policy with kauth.


Msdosfs and NFS would be fine but at least NFS will be out of scope ...

Beware that FFS integration will be difficult as blocks may be claimed
by snapshots and freed later when the last snapshot holding the block
gets removed. See ffs_snapblkfree().



--
J. Hannken-Illjes - hannken&amp;lt; at &amp;gt;eis.cs.tu-bs.de - TU Braunschweig (Germany)


&lt;/pre&gt;</description>
    <dc:creator>J. Hannken-Illjes</dc:creator>
    <dc:date>2013-05-17T10:33:47</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44134">
    <title>Re: [GSoC 2013] Implement file system flags to scrub data blocks before deletion</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44134</link>
    <description>&lt;pre&gt;
A better question would be: can this be done in a file system independent
way?  Or, at least, how can you minimize the number of file system specific
changes?
It's good to consider doing things for more than one filesystem, but I
wouldn't worry too much about what others to support.  I think you'll
have plenty to keep you busy with just these two.


One of the things you have on your list is "write a custom binary for mount",
and you don't mention modifying the standard mount program until much later.
If initially all you need is a flag to specify whether scrubbing should be on 
or not, I think you'll find that modifying mount_ffs will be much easier
than trying to re-write it.

A few questions that come to mind:
  Currently, removing a file is a relatively fast, atomic operation.  Are
  you planning on guaranteeing that the file is wiped before the unlink
  returns, potentially making the time to unlink much longer?  Or, will you
  end up with a list of blocks to clear after the unlink returns?

  Will the&lt;/pre&gt;</description>
    <dc:creator>Eric Haszlakiewicz</dc:creator>
    <dc:date>2013-05-17T05:28:54</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44133">
    <title>[GSoC 2013] Implement file system flags to scrub data blocks before deletion</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44133</link>
    <description>&lt;pre&gt;Hello,

I have received some comments on my project proposal, which can be found
https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/psie/1 ,
however it would be great if I could detail more points.

May I ask about your opinion on:
1) What file system(s) besides ffs and ext2fs could be modified to
benefit users,
2) What user space binaries have to be changed?

I am finding figuring out these two a little troubling, as I don't
want to miss anything.
Any other comments/suggestions are also more then welcome.

I am not planning to implement undelete instead, unless it is really wanted.

Mrs. S.P.Zeidler suggested I posted here, yet I started on
tech-security, I apologize and hope discussion won't diverge.

Regards,

Przemyslaw Sierocinski

&lt;/pre&gt;</description>
    <dc:creator>Przemysław Sierociński</dc:creator>
    <dc:date>2013-05-16T19:34:06</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44132">
    <title>frozen netbsd-6-rc4</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44132</link>
    <description>&lt;pre&gt;hello,

I am using netbsd-6-rc4 at a dell 1850. the server works only as router. 
it is connected with an lacp port-channel (4*1gb) to a cisco catalyst 
switch.

sometimes (1/day or more often) the system cpu usage increases to 300 
percent or more. in some cases netbsd is frozen (also the kernel 
debugger), in other cases netbsd continues to a normal work after some 
minutes.

The top command shows the following:

load averages:  0.76,  0.77,  0.58;               up 4+03:49:27       11:31:11
33 processes: 31 sleeping, 2 on CPU
CPU0 states:  6.2% user,  0.0% nice, 18.8% system, 11.2% interrupt, 63.9% idle
CPU1 states:  5.0% user,  0.0% nice, 12.8% system,  3.6% interrupt, 78.6% idle
Memory: 279M Act, 153M Inact, 6036K Wired, 20M Exec, 152M File, 296M Free
Swap: 4506M Total, 4506M Free

   PID USERNAME PRI NICE   SIZE   RES STATE      TIME   WCPU    CPU COMMAND
     0 root       0    0     0K 6928K CPU/1     13:37  0.00%   277% [system]
   464 root      43    0   316M  238M parked/0  21.4H 32.47% 32.47% named&lt;/pre&gt;</description>
    <dc:creator>6bone&lt; at &gt;6bone.informatik.uni-leipzig.de</dc:creator>
    <dc:date>2013-05-13T06:35:43</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44128">
    <title>Re: pchb&lt; at &gt;acpi again</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44128</link>
    <description>&lt;pre&gt;
I guess you're thinking about making an MI acpi_pci_intr_map() that
can be called from pci_intr_map() on both x86 and ia64?   that sounds reasonable.
I can try doing that but I'm not sure when I'll have time for it.

-Chuck

&lt;/pre&gt;</description>
    <dc:creator>Chuck Silvers</dc:creator>
    <dc:date>2013-05-06T01:42:33</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44127">
    <title>Re: Question about pool(9) sizes</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44127</link>
    <description>&lt;pre&gt;
mlelstv&amp;lt; at &amp;gt;serpens.de (Michael van Elst) writes:


If I follow correctly, there are two ways to fail:

  no free objects, and at page limit ("the pool limit")

  no free objects, not at page limit, but allocating a page failed


But the second path is complicated based on PR_WAITOK and PR_LIMITFAIL.


But, the OP's pool looks happy.
&lt;/pre&gt;</description>
    <dc:creator>Greg Troxel</dc:creator>
    <dc:date>2013-05-04T11:19:05</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44126">
    <title>Re: Question about pool(9) sizes</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44126</link>
    <description>&lt;pre&gt;



Size is not the number of objects in the pool.


A pool manages a set of equally sized items, for scxspl an item
is a scsipi_xfer structure.

Size     = the size of an item
Requests = number of item allocation attempts
Fail     = number of item allocation failures
Releases = number of item deallocations
Pgreq    = number of page allocation attempts
Pgrel    = number of page deallocations
Npage    = number of currently allocated pages
Nhiwat   = maximum number of allocated pages over pool lifetime
Minpg    = Minimum number of pages to keep
Maxpg    = limit to the number of pages that can be allocated (inf == no limit)
Idle     = Number of pages without item allocations


Maxpg determines the maximum pool size. Each page can contain
a fixed number of items which is about pagesize/itemsize,
the precise value depends on wether a page also includes
a header and on alignment restrictions of the item and
is a constant for the pool that isn't reported by vmstat.

If Fail &amp;gt; 0 then most likely the pool limit has b&lt;/pre&gt;</description>
    <dc:creator>Michael van Elst</dc:creator>
    <dc:date>2013-05-04T07:58:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44125">
    <title>Re: Question about pool(9) sizes</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.devel.kernel/44125</link>
    <description>&lt;pre&gt;
Brian Buhrow &amp;lt;buhrow&amp;lt; at &amp;gt;nfbcal.org&amp;gt; writes:


First, I suggest reading the following, if you haven't already:

    http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29.4759
    http://www.usenix.org/event/usenix01/bonwick.html

size is the number of bytes in each object - look at vmstat -m and
kmem-N.  pools allocate fixed-size objects so they can be efficienctly
packed into pages (see the first paper above).  The pool is entirely
unallocated, beacuse requests-releases==0.  Note that fail is 0, which
means no requests were denied.  There are 9 pages in the pool, and
probably there are 24 objects per page, so 216 unallocated presently.

Pools are designed to return pages to the kernel vm system if they are
not needed, and to get pages when needed.  So that line looks like a
very large number of alloc/free, but with no failures and not a lot
still allocated.  Hard to really be sure, but it looks entirely healthy
to me.

    
&lt;/pre&gt;</description>
    <dc:creator>Greg Troxel</dc:creator>
    <dc:date>2013-05-04T00:59:59</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.os.netbsd.devel.kernel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.os.netbsd.devel.kernel</link>
  </textinput>
</rdf:RDF>
