I was thinking along the lines of adding a command, job_size_allowed = default, (l)arge, (xl)arge, (j)umbo with using those in where you do the check FIO_MAX_JOBS or REAL_MAX_JOBS. Default=1 Large=1.5 XLarge=2 Jumbo=3 char output[(REAL_MAX_JOBS*job_size_allowed) + 512], *p = output; Sorry if the code is off/wrong, I have spent the last 5 days doing nothing but perl and bash scripting along with a twist of SQL so my brain is mush :P I used to test RAID code for a living so I wasn't about to start digging since I don't know the code well enough which means that if I push in on one side something else will more than likely pop out on the other. Looking at what your describing vs what I was thinking it sounds like your approach of setting it up to allow for a more dynamic range would be a more elegant approach that would serve better in the long run. Thanks, Roger -----Original Message----- From: Jens Axboe [mailto:axboe@xxxxxxxxx] Sent: Friday, April 20, 2012 2:41 AM To: Roger Sibert Cc: fio@xxxxxxxxxxxxxxx Subject: Re: segfault runninng fio against 2048 jobs On 04/18/2012 09:46 PM, Roger Sibert wrote: > I verified the patch in fio-2.0.7-11-g7907 and that does indeed look to > take care of the issue. (Many thanks for that) > > Also in follow up I changed the max job limit to 5120 and it seems to > run properly against that as well. > > Question though, is there any reason you have a REAL_MAX_JOBS in fio.h > and then a FIO_MAX_JOBS in os.h. First glance at it just shows that the > init.c code uses FIO_MAX_JOBS in for the thread check and then later on > it uses REAL_MAX_JOBS for the job check except that max_jobs is set > equal to FIO_MAX_JOBS. It may be that the answer to my question is the > os-mac.h file which means you have a smaller thread count ... maybe then > the result is just a small adjustment in the error print to show you > have exceeded the max # of jobs and or max # of threads. OSX has a seriously small max segment by default, hence the split and smaller value there. I should probably make the thread_data array be segmented, so that fio could support an arbitrary number of jobs regardless of the max shm segment size. So far it hasn't been a huge problem. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe fio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
