mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jody McIntyre <scjody@modernduck.com>
To: Parag Warudkar <kernel-stuff@comcast.net>
Cc: Dan Dennedy <dan@dennedy.org>, Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org,
	Linux1394-Devel <linux1394-devel@lists.sourceforge.net>
Subject: Re: [PATCH] ohci1394: dma_pool_destroy while in_atomic() && irqs_disabled()
Date: Sat, 19 Feb 2005 01:36:32 -0500	[thread overview]
Message-ID: <20050219063632.GE9231@conscoop.ottawa.on.ca> (raw)
In-Reply-To: <200502181042.47404.kernel-stuff@comcast.net>

On Fri, Feb 18, 2005 at 10:42:46AM -0500, Parag Warudkar wrote:
> On Friday 18 February 2005 10:32 am, Dan Dennedy wrote:
> > I have tested the patches (including for allocation), and it is working
> > great, but should I only commit for now the deallocation patch? Hmm..
> > which is worse the debug or the 200K waste?
> Thanks for following it up.
> 
> IMHO, we should commit both patches for now since we don't have an alternative 
> solution yet. 

I disagree because the impact of this bug is small.  How often do you start
an ISO receive?  If you think it needs to be fixed urgently, please
explain why - maybe I'm just missing somethnig.

> Jody - Is the 200K waste for sure or do you want me to verify it by some 
> means? ( Reason I am asking is firstly, Dave Brownell was quite sure it 
> wasn't that costly and secondly, I am hoping it isn't.. ;)

I'm not sure, but I looked through the code and it seems to allocate:
 - 16 buffers of 2x PAGE_SIZE (= 131072 on i386)
 - 16 buffers of PAGE_SIZE (= 65536 on i386)
 - various other smaller structures.

I'm not sure how to actually _measure_ how much memory this is using.
slabinfo isn't useful, at least on my system, because the 1394
allocations get lost in the noise of other activity.

If you really need this fixed quickly, I'll find some time this weekend
to examine the locks.  In particular, I'm not sure what host_info_lock
protects or why it needs to be held in so many places with irqs disabled.

Jody

> 
> Parag

-- 

  reply	other threads:[~2005-02-19  6:38 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-30 20:54 Parag Warudkar
2005-01-30 21:17 ` Andrew Morton
2005-01-30 22:49   ` Parag Warudkar
2005-01-30 23:02     ` Andrew Morton
2005-01-31  1:19       ` Parag Warudkar
2005-01-31 23:26         ` Parag Warudkar
2005-02-11 15:35         ` Dan Dennedy
2005-02-11 18:43           ` Jody McIntyre
2005-02-12  3:54             ` Parag Warudkar
2005-02-18 15:32               ` Dan Dennedy
2005-02-18 15:42                 ` Parag Warudkar
2005-02-19  6:36                   ` Jody McIntyre [this message]
2005-02-19 15:06                     ` Parag Warudkar
2005-02-19 19:36 David Brownell
2005-02-19 20:50 ` Parag Warudkar
2005-02-19 21:13   ` David Brownell
2005-02-19 22:55 ` Jody McIntyre

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050219063632.GE9231@conscoop.ottawa.on.ca \
    --to=scjody@modernduck.com \
    --cc=akpm@osdl.org \
    --cc=dan@dennedy.org \
    --cc=kernel-stuff@comcast.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux1394-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®