diff for duplicates of <553006BF.6050306@oracle.com> diff --git a/a/1.txt b/N1/1.txt index 46fe8da..f0b9296 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -27,3 +27,27 @@ Chuck and Doug talked about incoming bake-a-thon plan, Doug has a small IB test NFSoRDMA performance: (Shirley, Chuck, SteveW) --------------------- +>From ftrace function-graph report, both large I/O workload and intensive CPU workload showed that the interrupts and scheduling are two key contributes to NFS operations (READ, WRITE, GETATTR...). In CPU intensive workload like make kernel in the background, wake_up_bit is too costly. Is that possible to replace wake_up_bit? Chuck mentioned that it used to be wait queue, wake up queue. We could try it to see any performance difference. To reduce the interrupts, Shirley is trying to see the performance gain from disabling interrupts and wait a bit, there are some throughput gain with heavy cpu utilization. She will continue to investigate it. Chuck has tried to move completion up call from CQ to WQ context. There is no more items queuing in receiving queue, only saw one or two. SteveW repli + ed that the queue should be built in this scenarios. Shirley thinks without addressing the scheduling issue in this workload, it might not be possible to see any other improvement. + +Doug works on performance evaluation work in his large system test bed. He will set up more accurate baseline performance, then investigate where to optimized in the stack as well as the HW. + +We are looking for good tools to simulate real workloads, like database workload. Right now we are using fio to simulate. We need to define real workloads. If anybody has any suggestion, that would be great. Shirley will send a separated email thread to discuss it. + +Storage RDMA technology (Shirley, Chuck, Doug) +----------------------- +Whether can we use this call to cover iSCSI/iSER/SRP work? The performance issues will be different, however both of they use RDMA as transport, so it might be helpful to discuss storage RDMA work here as long as NFSoRDMA is still the focus and we have time to discuss about the work. + + +Feel free to reply here for anything missing or incorrect. Thanks everyone for joining the call and providing valuable inputs/work to the community to make NFSoRDMA better. + +Cheers, +Shirley + + + + +-- +To unsubscribe from this list: send the line "unsubscribe linux-rdma" in +the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org +More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N1/content_digest index e2ba146..920e747 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -3,25 +3,26 @@ "ref\054C7D09D.3000600@oracle.com\0" "ref\054C937BA.9020606@oracle.com\0" "ref\0552EE56E.5060705@oracle.com\0" - "From\0Shirley Ma <shirley.ma@oracle.com>\0" + "ref\0552EE56E.5060705-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org\0" + "From\0Shirley Ma <shirley.ma-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>\0" "Subject\0NFSoRDMA bi-weekly developers meeting minutes (4/16/15)\0" "Date\0Thu, 16 Apr 2015 12:00:15 -0700\0" - "To\0Chuck Lever <chuck.lever@oracle.com>" - Jeff Becker <jeffrey.c.becker@nasa.gov> - Steve Wise <swise@opengridcomputing.com> - Steve Dickson <SteveD@redhat.com> - <Devesh.Sharma@emulex.com> <Devesh.Sharma@emulex.com> - Rupert Dance <rsdance@soft-forge.com> - Doug Ledford <dledford@redhat.com> - Anna Schumaker <Anna.Schumaker@netapp.com> - <yanb@mellanox.com> <yanb@mellanox.com> + "To\0Chuck Lever <chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>" + Jeff Becker <jeffrey.c.becker-NSQ8wuThN14@public.gmane.org> + Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org> + Steve Dickson <SteveD-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> + <Devesh.Sharma-laKkSmNT4hbQT0dZR+AlfA@public.gmane.org> <Devesh.Sharma-laKkSmNT4hbQT0dZR+AlfA@public.gmane.org> + Rupert Dance <rsdance-rzwDkyJvnYokmLvzuZlaBw@public.gmane.org> + Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> + Anna Schumaker <Anna.Schumaker-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org> + <yanb-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> <yanb-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> Coulter - Susan K <skc@lanl.gov> - wendy.cheng@intel.com - Dominique Martinet <dominique.martinet@cea.fr> - " sprabhu@redhat.com\0" - "Cc\0linux-rdma <linux-rdma@vger.kernel.org>" - " Linux NFS Mailing List <linux-nfs@vger.kernel.org>\0" + Susan K <skc-YOWKrPYUwWM@public.gmane.org> + wendy.cheng-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org + Dominique Martinet <dominique.martinet-KCE40YydGKI@public.gmane.org> + " sprabhu-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org\0" + "Cc\0linux-rdma <linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>" + " Linux NFS Mailing List <linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>\0" "\00:1\0" "b\0" "Attendees:\n" @@ -52,6 +53,30 @@ "Chuck and Doug talked about incoming bake-a-thon plan, Doug has a small IB test et up, he can bring it to test. Solaris requires particular HCAs to work. They will talk to SteveD about several different possibilities to make it work.\n" "\n" "NFSoRDMA performance: (Shirley, Chuck, SteveW)\n" - --------------------- + "---------------------\n" + ">From ftrace function-graph report, both large I/O workload and intensive CPU workload showed that the interrupts and scheduling are two key contributes to NFS operations (READ, WRITE, GETATTR...). In CPU intensive workload like make kernel in the background, wake_up_bit is too costly. Is that possible to replace wake_up_bit? Chuck mentioned that it used to be wait queue, wake up queue. We could try it to see any performance difference. To reduce the interrupts, Shirley is trying to see the performance gain from disabling interrupts and wait a bit, there are some throughput gain with heavy cpu utilization. She will continue to investigate it. Chuck has tried to move completion up call from CQ to WQ context. There is no more items queuing in receiving queue, only saw one or two. SteveW repli\n" + " ed that the queue should be built in this scenarios. Shirley thinks without addressing the scheduling issue in this workload, it might not be possible to see any other improvement.\n" + "\n" + "Doug works on performance evaluation work in his large system test bed. He will set up more accurate baseline performance, then investigate where to optimized in the stack as well as the HW.\n" + "\n" + "We are looking for good tools to simulate real workloads, like database workload. Right now we are using fio to simulate. We need to define real workloads. If anybody has any suggestion, that would be great. Shirley will send a separated email thread to discuss it.\n" + "\n" + "Storage RDMA technology (Shirley, Chuck, Doug)\n" + "-----------------------\n" + "Whether can we use this call to cover iSCSI/iSER/SRP work? The performance issues will be different, however both of they use RDMA as transport, so it might be helpful to discuss storage RDMA work here as long as NFSoRDMA is still the focus and we have time to discuss about the work.\n" + "\n" + "\n" + "Feel free to reply here for anything missing or incorrect. Thanks everyone for joining the call and providing valuable inputs/work to the community to make NFSoRDMA better.\n" + "\n" + "Cheers,\n" + "Shirley\n" + "\n" + "\n" + "\n" + "\n" + "--\n" + "To unsubscribe from this list: send the line \"unsubscribe linux-rdma\" in\n" + "the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org\n" + More majordomo info at http://vger.kernel.org/majordomo-info.html -45c7a17cb71d1899a3d294b1d762ee396626c7ebfda5418516bd924c823b2622 +4d627f50a98d48ac4815104a69093958db1daffb4f54b348f5ea08d756f3a7cb
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.