Quoth Unga unga...@yahoo.com:
I think you may be reading too much into the malloc manpage.� When it
mentions the use of per-thread small-object caches to avoid locking it's
talking about performance, not thread safety.� Allocations of all sizes
are thread-safe, the library just assumes
On Wed, Mar 27, 2013 at 10:39:16PM -0700, Unga wrote:
I think you may be reading too much into the malloc manpage.? When it
mentions the use of per-thread small-object caches to avoid locking it's
talking about performance, not thread safety.? Allocations of all sizes
are thread-safe, the
On 28.03.2013 02:43, Adrian Chadd wrote:
My main concern with the new stuff is that it requires CAM and that's
reasonably big compared to the standalone ATA code.
It'd be nice if we could slim down the CAM stack a bit first; it makes
embedding it on the smaller devices really freaking painful.
Alexander Motin wrote this message on Thu, Mar 28, 2013 at 09:17 +0200:
On 28.03.2013 02:43, Adrian Chadd wrote:
My main concern with the new stuff is that it requires CAM and that's
reasonably big compared to the standalone ATA code.
It'd be nice if we could slim down the CAM stack a bit
Le jeudi 28 mars 2013 11:05:58 Daniel O'Connor a écrit :
On 27/03/2013, at 18:43, David Demelier demelier.da...@gmail.com wrote:
Yesterday I had a panic on my laptop. Unfortunately the SU+J was not
able to recovery the file system, the error was something like :
Unknown error: Help!
On Thu, 2013-03-28 at 09:17 +0200, Alexander Motin wrote:
On 28.03.2013 02:43, Adrian Chadd wrote:
My main concern with the new stuff is that it requires CAM and that's
reasonably big compared to the standalone ATA code.
It'd be nice if we could slim down the CAM stack a bit first; it
On Wed, 27 Mar 2013 17:43:07 -0700
Adrian Chadd adr...@freebsd.org wrote:
My main concern with the new stuff is that it requires CAM and that's
reasonably big compared to the standalone ATA code.
It'd be nice if we could slim down the CAM stack a bit first; it makes
embedding it on the
On Mar 27, 2013, at 6:43 PM, Adrian Chadd adr...@freebsd.org wrote:
My main concern with the new stuff is that it requires CAM and that's
reasonably big compared to the standalone ATA code.
From a code execution standpoint? No, it's not.
It'd be nice if we could slim down the CAM stack a
On Mar 28, 2013, at 8:00 AM, Ian Lepore i...@freebsd.org wrote:
On Thu, 2013-03-28 at 09:17 +0200, Alexander Motin wrote:
On 28.03.2013 02:43, Adrian Chadd wrote:
My main concern with the new stuff is that it requires CAM and that's
reasonably big compared to the standalone ATA code.
It'd
Hello, Aleksandr.
You wrote 28 марта 2013 г., 18:09:53:
It'd be nice if we could slim down the CAM stack a bit first; it makes
embedding it on the smaller devices really freaking painful.
AR /me never seen embedded devices with ATA/SATA and less than 64MB of RAM.
AR (i386/i486 old machines
On 28 March 2013 09:05, Lev Serebryakov l...@freebsd.org wrote:
Yes: USB UMASS. It uses CAM too, and useful for very small systems,
like 4MiB FLASH and 16MiB RAM (yes, whole system image, kernel and
all, should be packed to 4MiB).
Please note, Adrian speaks about CAM, not only CAM +
.. and before you ask - yes, there are embedded boards with limited
RAM that also have ATA ports. :-)
Adrian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to
In message
CAJ-Vmo=qATZHubkKZ2heiJ3528e__JG4RLru7LU9rwP5_EwT=g...@mail.gmail.com, Adrian
Chadd wri
tes:
On 28 March 2013 09:05, Lev Serebryakov l...@freebsd.org wrote:
adrian@freefall:~/public_html/ath$ cat AP121-nodebug.txt | egrep
'(cam_|umass|scsi_)' | awk '{a+=$4} END {print a}'
190904
It
On Thu, 28 Mar 2013, Ian Lepore wrote:
On Thu, 2013-03-28 at 09:17 +0200, Alexander Motin wrote:
On 28.03.2013 02:43, Adrian Chadd wrote:
My main concern with the new stuff is that it requires CAM and that's
reasonably big compared to the standalone ATA code.
It'd be nice if we could slim
On 28 March 2013 10:26, Poul-Henning Kamp p...@phk.freebsd.dk wrote:
Isn't there some kernel compile-time option to eliminate the huge
tables used for errormessages etc ?
Yup. It doesn't save all that much in the grand scheme of things.
Doubly so since my secondary size constraint is an 896k
15 matches
Mail list logo
