lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 15 Mar 2010 21:28:13 +0200 From: Felipe Balbi <me@...ipebalbi.com> To: Micha?? Nazarewicz <m.nazarewicz@...sung.com> Cc: me@...ipebalbi.com, linux-usb@...r.kernel.org, David Brownell <dbrownell@...rs.sourceforge.net>, gregkh@...e.de, linux-kernel@...r.kernel.org, Marek Szyprowski <m.szyprowski@...sung.com>, Kyungmin Park <kyungmin.park@...sung.com> Subject: Re: [PATCH] USB: f_mass_storage: dynamic buffers for better alignment On Mon, Mar 15, 2010 at 08:20:08PM +0100, Micha?? Nazarewicz wrote: > > On Mon, Mar 15, 2010 at 11:09:55AM +0100, Michal Nazarewicz wrote: > >> "Static" buffers in fsg_buffhd structure (ie. fields which are arrays > >> rather then pointers to dynamically allocated memory) are not aligned > >> to any "big" power of two which may lead to poor DMA performance > > On Mon, 15 Mar 2010 19:10:21 +0100, Felipe Balbi <me@...ipebalbi.com> wrote: > > not so true as you can add __attribute__ ((aligned(32))) to those. > > I admit, I haven't thought about that. Some fields rearrangement > could help avoid some padding but yes, it can be done. > > However, there is one more thing I've had in mind. Each buffer > is 4 pages (16 KiB) and there are two such buffers in struct > fsg_common therefore the whole size of the structure is > 9 pages (> 32 KiB). > > I've been simply concerned about using kamlloc() for such big > structures so in the end decided to split it into 3 allocations. > > Maybe I'm overeating though? Or maybe vmalloc() would solve those > problems? But then again, vmalloc() could degrade DMA performance > on systems w/o scatter-gather. > > What do you think? I have no opinion anymore :-p I can only think about the devices I've been working on which would be a pain to allocate so much memory and would suffer if you use vmalloc() too, so both would be a no-no for me :-p > bh = common->buffhds; > rc = -ENOMEM; > i = FSG_NUM_BUFFERS; > for(;;) { > bh->buf = kmalloc(FSG_BUFLEN, GFP_KERNEL); > if (unlikely(!bh->buf)) > goto error_release; > if (!--i) > break; > bh->next = bh + 1; > ++bh; > } > bh->next = common->buffhds; > > What do you think? how about ? for (i = FSG_NUM_BUFFER; i; i--, ++bh) { bh->buf = kmalloc(FSG_BUFLEN, GFP_KERNEL); if (!bh->buf) goto error_release; } -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists