From: Pete Zaitcev <zaitcev@redhat.com>
To: stodden@in.tum.de, Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: pci_pool reap?
Date: Sun, 10 Feb 2002 21:49:41 -0500 [thread overview]
Message-ID: <200202110249.g1B2nfx27479@devserv.devel.redhat.com> (raw)
In-Reply-To: <mailman.1013388420.27877.linux-kernel2news@redhat.com>
In-Reply-To: <mailman.1013388420.27877.linux-kernel2news@redhat.com>
> is it true that pci pools are never shrunk? or am i just missing the
> point where it happens?
>
> try_to_free_pages() seems to care just about kmem_caches.
Yes, they do not shrink. When David-B wrote them, they shrunk.
Later I found an interrupt availability violation (pci_pool_free
can be called from an interrupt, it can call pci_free_consistent,
which cannot be called from an interrupt), so we got it removed.
There is a certain controversy about pci_free_consistent called
from an interrupt. It seems that most architectures would
have no problems, and only arm is problematic. RMK says that
it's not intrinsicly so, this is one of my TODO notes:
## 2001/12/18
<zaitcev> rmk: you do have some stuff broken, for instance using vmalloc for
pci_alloc_consistent was a major pain for everyone else
<_rmk_> zaitcev: errrrrrrrr
<_rmk_> zaitcev: I don't use vmalloc there, never have done.
<_rmk_> I use alloc_pages and ioremap
<_rmk_> You're thinking about the sa1100 people who decided to make pci_map_*
fail I think.
<zaitcev> hmm. I'll re-investigate.
<_rmk_> which... is not something I agree with either.
<_rmk_> but quite honestly, with Intel breaking the hardware soo badly, it
being popular and continues to be reused on other platforms, its
something we're going to have to live with.
Wanna take it up personally? I seem never to have a time.
-- Pete
next parent reply other threads:[~2002-02-11 2:50 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.1013388420.27877.linux-kernel2news@redhat.com>
2002-02-11 2:49 ` Pete Zaitcev [this message]
2002-02-11 3:12 ` pci_pool reap? Alan Cox
2002-02-10 20:20 ` Gérard Roudier
2002-02-12 2:44 ` David S. Miller
2002-02-11 20:34 ` Gérard Roudier
2002-02-12 15:36 ` Daniel Stodden
2002-02-11 21:10 ` Gérard Roudier
2002-02-12 21:14 ` Daniel Stodden
2002-02-12 15:48 ` Russell King
2002-02-12 15:50 ` David S. Miller
2002-02-12 15:59 ` Russell King
2002-02-12 17:27 ` Daniel Stodden
2002-02-12 15:49 ` David S. Miller
2002-02-11 0:44 Daniel Stodden
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=200202110249.g1B2nfx27479@devserv.devel.redhat.com \
--to=zaitcev@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=stodden@in.tum.de \
/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