I agree, we saw this as well but I switched our default to quantize(RequestMemory, 256)
perhaps we can split the difference and all be happy. how about: quantize(RequestMemory, 128) ? Cheers, Tim ----- Original Message ----- > From: "Brian Bockelman" <bbock...@cse.unl.edu> > To: "condor-devel@cs.wisc.edu Developers" <condor-devel@cs.wisc.edu> > Sent: Saturday, October 20, 2012 10:43:31 AM > Subject: [Condor-devel] Fix MODIFY_REQUEST_EXPR_REQUESTMEMORY? > > Hi, > > What do folks think about changing the default > MODIFY_REQUEST_EXPR_REQUESTMEMORY? > > Looking at our current cluster, it's mostly just doing damage, as it > can greatly increase the job's memory request. See below - I don't > feel like adding up all the memory rounding, but the last two rows > correspond to 800GB of RAM wasted. > > The worst case scenario is the default wastes 25% of throughput. In > practice, we sometimes come close to this. No efficiencies gained > in the negotiator is worth that. > > I recommend changing the default to: > > MODIFY_REQUEST_EXPR_REQUESTMEMORY = quantize(RequestMemory, 100) > > Brian > > > condor_q -g -format "%d\n" RequestMemory | sort | uniq -c | sort -n > 4882 1900 > 6882 2500 > > condor_status -const 'DynamicSlot=?=TRUE' -format "%d\n" Memory | > > sort | uniq -c | sort -n > 10 2676 > 66 2415 > 81 2376 > 100 2250 > 132 2970 > 134 2392 > 210 2404 > 294 2990 > 360 2700 > 586 3005 > 702 3220 > > > _______________________________________________ > Condor-devel mailing list > Condor-devel@cs.wisc.edu > https://lists.cs.wisc.edu/mailman/listinfo/condor-devel _______________________________________________ Condor-devel mailing list Condor-devel@cs.wisc.edu https://lists.cs.wisc.edu/mailman/listinfo/condor-devel
