Jeff Garzik wrote:
Tejun Heo wrote:
Jeff Garzik wrote:
A few days before that, both PMP and SAS /were/ slated for 2.6.24, and
after I fix the design problems, they will be again.
One way or another, upstream will /not/ be doing polling PMP in 2.6.24.
Just an update to let you know that
Tejun Heo wrote:
Jeff Garzik wrote:
A few days before that, both PMP and SAS /were/ slated for 2.6.24, and
after I fix the design problems, they will be again.
One way or another, upstream will /not/ be doing polling PMP in 2.6.24.
Just an update to let you know that I've been working on it.
Jeff Garzik wrote:
A few days before that, both PMP and SAS /were/ slated for 2.6.24, and
after I fix the design problems, they will be again.
One way or another, upstream will /not/ be doing polling PMP in 2.6.24.
Just an update to let you know that I've been working on it. sata_sil24
Tejun Heo wrote:
Jeff Garzik wrote:
Mark Lord wrote:
Linux kernel development is supposed to happen incrementally nowadays.
Get a nice working solution in place, and then enhance/tune it.
It's not about enhancing and tuning.
It's about me (and/or James B) having to __undo__ the current code,
Jeff Garzik wrote:
Tejun Heo wrote:
Jeff Garzik wrote:
Mark Lord wrote:
Linux kernel development is supposed to happen incrementally nowadays.
Get a nice working solution in place, and then enhance/tune it.
It's not about enhancing and tuning.
It's about me (and/or James B) having to
Mark Lord wrote:
Jeff Garzik wrote:
Tejun Heo wrote:
Jeff Garzik wrote:
Mark Lord wrote:
Linux kernel development is supposed to happen incrementally nowadays.
Get a nice working solution in place, and then enhance/tune it.
It's not about enhancing and tuning.
It's about me (and/or James
Polling PMP 2.6.24 is completely unacceptable. It screws the 2.6.24 SAS
driver releases out of PMP.
No PMP in 2.6.24 screws PMP users, who outnumber SAS users by a few
thousand to one I suspect.
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to
Alan Cox wrote:
Polling PMP 2.6.24 is completely unacceptable. It screws the 2.6.24 SAS
driver releases out of PMP.
No PMP in 2.6.24 screws PMP users, who outnumber SAS users by a few
thousand to one I suspect.
no-PMP-in-2.6.24 is not happening, so that's rather irrelevant.
Jeff
Mark Lord wrote:
Linux kernel development is supposed to happen incrementally nowadays.
Get a nice working solution in place, and then enhance/tune it.
It's not about enhancing and tuning.
It's about me (and/or James B) having to __undo__ the current code, just
to get things working on an
Jeff Garzik wrote:
Polling PMP 2.6.24 is completely unacceptable. It screws the 2.6.24 SAS
driver releases out of PMP.
Not merging PMP has about the same effect for SAS, right?
I pulled your last PMP patchset, and will now endeavor to fix the API
prior to 2.6.24 merge window opening.
I
Jeff Garzik wrote:
Mark Lord wrote:
Linux kernel development is supposed to happen incrementally nowadays.
Get a nice working solution in place, and then enhance/tune it.
It's not about enhancing and tuning.
It's about me (and/or James B) having to __undo__ the current code, just
to get
On 9/28/07, Jeff Garzik [EMAIL PROTECTED] wrote:
(my last response only addressed -mm)
Mark Lord wrote:
I believe the point was that getting things into libata is glacial
IMHO would say that there are two causes of that:
1) I am sometimes slow in merging, part of which is my own fault, and
Tejun Heo wrote:
Jeff Garzik wrote:
[--snip--]
There, even the concept of port is fluid, and the libata EH model of
freezing and thawing a port (with the desired irq-off result) just
doesn't fit the hardware.
Well, the current model was developed while struggling with the first
generation PMP
Tejun Heo wrote:
Jeff Garzik wrote:
Is this NACK on the patchset or can we update PMP access later?
Sorry, yes, it is a NAK: polling should not be requirement.
I considered making multi-protocol -qc_issue() a requirement too, but
that seemed like it might delay things too much. But consider
Alan Cox wrote:
Aieee... Another merge delay. I wish the review process proceeded a bit
swifter. The patchset has been around literally for years now and
submitted for review six times if I have the take number right. :-(
Agreed - thats one reason I stick everything in -mm. Its taking
Jeff Garzik wrote:
Is this NACK on the patchset or can we update PMP access later?
Sorry, yes, it is a NAK: polling should not be requirement.
I considered making multi-protocol -qc_issue() a requirement too, but
that seemed like it might delay things too much. But consider this a
Alan Cox wrote:
This doesn't affect Tejun or anyone else really, but going through -mm
tends to gum up the works. Your patches wind up not applying to
libata#upstream, in which case they get dropped and I assume Andrew or
someone will resend usable versions.
Its the only way to get testing
This doesn't affect Tejun or anyone else really, but going through -mm
tends to gum up the works. Your patches wind up not applying to
libata#upstream, in which case they get dropped and I assume Andrew or
someone will resend usable versions.
Its the only way to get testing done and get
Mark Lord wrote:
Jeff Garzik wrote:
..
As such, polling is simply an outmoded concept. It does not make
sense on new hardware, and forcing design decisions down that path
only lead to a cascade of similar design decisions -- pmp_read polling
being just one example of such a result.
A
Aieee... Another merge delay. I wish the review process proceeded a bit
swifter. The patchset has been around literally for years now and
submitted for review six times if I have the take number right. :-(
Agreed - thats one reason I stick everything in -mm. Its taking several
months for a
Tejun Heo wrote:
Is this NACK on the patchset or can we update PMP access later?
Ping?
--
tejun
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
So, there just hasn't been a real need so far. If interrupt overhead
becomes an issue, my first step would be to start programming the
interrupt coalescing hardware that comes in modern SATA controllers.
Another factor is queue sizes. You don't get 1024 entry queues on your
typical disk
Alan Cox wrote:
Jeff, seeing as Tejun's commitment is never in doubt here,
I really believe we should go with the existing PMP patchset
for 2.6.24 (unless the respin happens quickly enough).
This functionality is way overdue, and we shouldn't be impeding it
as long as we have been.
I would
Mark Lord wrote:
Jeff Garzik wrote:
Alan Cox wrote:
This doesn't affect Tejun or anyone else really, but going through
-mm tends to gum up the works. Your patches wind up not applying to
libata#upstream, in which case they get dropped and I assume Andrew
or someone will resend usable
(my last response only addressed -mm)
Mark Lord wrote:
I believe the point was that getting things into libata is glacial
IMHO would say that there are two causes of that:
1) I am sometimes slow in merging, part of which is my own fault, and I
can only promise to try and do better there.
On Fri, 28 Sep 2007 23:29:44 -0400 Jeff Garzik [EMAIL PROTECTED] wrote:
(my last response only addressed -mm)
Mark Lord wrote:
I believe the point was that getting things into libata is glacial
IMHO would say that there are two causes of that:
1) I am sometimes slow in merging, part of
Andrew Morton wrote:
On Fri, 28 Sep 2007 23:29:44 -0400 Jeff Garzik [EMAIL PROTECTED] wrote:
(my last response only addressed -mm)
Mark Lord wrote:
I believe the point was that getting things into libata is glacial
IMHO would say that there are two causes of that:
1) I am sometimes slow in
Jeff Garzik wrote:
Polling ALREADY makes the job of fixing SAS/SATA exception handling
difficult. Expanding polling to something SAS/SATA controllers treat as
fundamentally irq-driven and integrated with the rest of the command
flow is moving in the wrong direction.
To re-re-re-summarize,
Jeff Garzik wrote:
[--snip--]
There, even the concept of port is fluid, and the libata EH model of
freezing and thawing a port (with the desired irq-off result) just
doesn't fit the hardware.
Well, the current model was developed while struggling with the first
generation PMP hardware which
Here's one thing that jumps out at me, reviewing the PMP patchset:
PMP reads and writes require polling, which is not something we should
impose upon the design. Conversations with a port multiplier are
fundamentally packetized, and modern controllers treat these just like
the bazillion
Jeff Garzik wrote:
Just like the Linux kernel MM platform API presents 3 levels of page
table entries, even when the hardware may only have 2, libata high level
API _must_ be implemented as 100% asynchronous event driven API.
To be more clear, non-taskfile packets/commands should be
31 matches
Mail list logo
