Support for ~2144 SCSI discs

With the sard patch and a 64 bit system, you start having trouble at around 103 configured disks, because of the following line in sd_init() (sd.c), because kmalloc doesn't like allocating large chunks of memory:

        sd = kmalloc((sd_template.dev_max << 4) *
                                          sizeof(struct hd_struct),
                                          GFP_ATOMIC);

Without sard, you'd have problems past 512 disks.

With the sard patch, the hd_struct looks like the following:

struct hd_struct {
        long start_sect;
        long nr_sects;
        devfs_handle_t de;              /* primary (master) devfs entry  */

        int number;                     /* stupid old code wastes space  */

        /* Performance stats: */
        unsigned int ios_in_flight;
        unsigned int io_ticks;
        unsigned int last_idle_time;
        unsigned int last_queue_change;
        unsigned int aveq;

        unsigned int rd_ios;
        unsigned int rd_merges;
        unsigned int rd_ticks;
        unsigned int rd_sectors;
        unsigned int wr_ios;
        unsigned int wr_merges;
        unsigned int wr_ticks;
        unsigned int wr_sectors;
};

The caveat is that I'm looking at a patch that is a few months old (I couldn't find where the latest version of the kernel patch is).

jeremy

So even without my patch, sard doesn't support the previous limit of 128 devices.

Yes, when I was coding up the patch I noticed the use of GFP_ATOMIC in the allocation calls. I have two questions:
- can we use GFP_KERNEL instead (why use GFP_ATOMIC)
- can we switch to vmalloc() instead of kmalloc()?

Do the stats have to be kept on a per-partition basic? What about per-device instead?

				Regards,

					Richard....
Permanent: [email protected]
Current:   [email protected]