Alan Cox <[EMAIL PROTECTED]> wrote:
> O> I'm counting on kmalloc to return a cache aligned buffer. I found
> > some reason to think it does, but I don't remember offhand what that
>
> Its defined to
>
> > reason was, or if it's configurable per-architecture. The buffer has
> > to be both physically and virtually contiguous, I was tempted to just
> > allocate a page and waste some space but we've got 64K pages, so I'm a
> > bit more sensitive about that.
>
> Ok I was expecting a different approach if you mark the field with the
> magic ____cacheline_aligned tag after it (ie int foo ____blah_aligned;)
> the compiler should align it all for you , which is probably cleaner if
> it works.
I hadn't considered that approach due to the way the ata_port is allocated:
> libata-core.c:
> host = scsi_host_alloc(ent->sht, sizeof(struct ata_port));
>
> hosts.c:
> struct Scsi_Host *scsi_host_alloc(struct scsi_host_template *sht, int
> privsize)
> {
> shost = kzalloc(sizeof(struct Scsi_Host) + privsize, gfp_mask);
> }
The ata_port allocation is tacked onto the end of the Scsi_Host
allocation, so the start of ata_port will only be cache aligned if the
end of the Scsi_Host struct is, although that would be easy enough to
fix since it's currently aligned to an unsigned long boundary.
I like that approach better, since it's clearer what the intent is,
and it's easier. Is there any other way that the ata_port struct
might be used that would invalidate this? This one issue is the
extent of my knowledge of libata.
-
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
