Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 10 May 2006 09:30:27 +0930
From:      "Daniel O'Connor" <doconnor@gsoft.com.au>
To:        freebsd-hackers@freebsd.org
Cc:        Bharma Ji <bharmaji@gmail.com>
Subject:   Re: differences between M_CACHE, M_DEVBUF, M_TEMP
Message-ID:  <200605100930.28030.doconnor@gsoft.com.au>
In-Reply-To: <67beabb0605081559j3904ada3vb5a952cc3195ae44@mail.gmail.com>
References:  <67beabb0605081559j3904ada3vb5a952cc3195ae44@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart1261166.GfGITZO878
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Tuesday 09 May 2006 08:29, Bharma Ji wrote:
> I am trying to understand the difference in these three different memorie=
s.
> Code comments in kern_malloc.c says that M_DEVBUF should be used for devi=
ce
> driver. I didn't however see any major difference between the three
> memories. Can a device theoretically take up memory from  M_TEMP (or
> M_CACHE) segment? Similary can device drivers using M_DEVBUF also allocate
> from M_CACHE / M_TEMP if needed.

The M_* stuff is just a categorisation for memory allocations. Run vmstat -=
m=20
to see what I mean.

AFAIK the actual take has no bearing on the performance of the allocation=20
itself.

=2D-=20
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

--nextPart1261166.GfGITZO878
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (FreeBSD)

iD8DBQBEYS0c5ZPcIHs/zowRAgqvAKCScKFU0oVNRhKz4vXyjYmwTMoq1ACggD+6
Ce75GuHX/jjxAsvdoB09OXI=
=xlfU
-----END PGP SIGNATURE-----

--nextPart1261166.GfGITZO878--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200605100930.28030.doconnor>