On 11/4/24 17:42, Halil Pasic wrote: > On Thu, 31 Oct 2024 13:30:17 +0100 > Halil Pasic <pasic@xxxxxxxxxxxxx> wrote: > >> On Sat, 26 Oct 2024 07:58:39 +0800 >> Dust Li <dust.li@xxxxxxxxxxxxxxxxx> wrote: >> >>>> For some reason include/linux/wait.h does not offer a top level wrapper >>>> macro for wait_event with interruptible, exclusive and timeout. I did >>>> not spend too many cycles on thinking if that is even a combination that >>>> makes sense (on the quick I don't see why not) and conversely I >>>> refrained from making an attempt to accomplish the interruptible, >>>> exclusive and timeout combo by using the abstraction-wise lower >>>> level __wait_event interface. >>>> >>>> To alleviate the tx performance bottleneck and the CPU overhead due to >>>> the spinlock contention, let us increase SMC_WR_BUF_CNT to 256. >>> >>> Hi, >>> >>> Have you tested other values, such as 64? In our internal version, we >>> have used 64 for some time. >> >> Yes we have, but I'm not sure the data is still to be found. Let me do >> some digging. >> > > We did some digging and according to that data 64 is not likely to cut > it on the TX end for highly parallel request-response workload. But we > will measure some more these days just to be on the safe side. > >>> >>> Increasing this to 256 will require a 36K continuous physical memory >>> allocation in smc_wr_alloc_link_mem(). Based on my experience, this may >>> fail on servers that have been running for a long time and have >>> fragmented memory. >> >> Good point! It is possible that I did not give sufficient thought to >> this aspect. >> > > The failing allocation would lead to a fallback to TCP I believe. Which > I don't consider a catastrophic failure. > > But let us put this patch on hold and see if we can come up with > something better. FTR, I marked this patch as 'changes requested' given the possible risk of regressions (more frequent fallback to TCP). We can revive it should an agreement be reached. Thanks, Paolo
