[LU-7655] To drop write data on OST to help performance benchmark Created: 12/Jan/16 Updated: 20/Jul/17 Resolved: 06/Dec/16 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | Lustre 2.9.0 |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Jinshan Xiong (Inactive) | Assignee: | Jinshan Xiong (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||||||
| Rank (Obsolete): | 9223372036854775807 | ||||||||||||
| Description |
|
By setting a fail_loc on the OST side, OST_WRITE RPC will only create transaction and update file size if necessary, but the actual data will be dropped. This will be of great help to performance benchmark on client side. |
| Comments |
| Comment by Li Xi (Inactive) [ 23/Jun/16 ] |
|
This is a good idea. And we can do this to read too. When I was tuning the readahead alogirthm, I made a patch which always set the reading page updated on OST side. And in this way, we can get read peformance of over 3GB/s even with only one node. |
| Comment by Li Xi (Inactive) [ 23/Jun/16 ] |
|
BTW, I am wondering whether we could add some regression tests for performance. Of course, there will be some hardware requirements in the test. It is not likely that the performance regression tests can be done in a virtual machine. But it might be possible at least for some operations if we could provide similar mechanism like this one to provide huge performance with limited hardware. For example, as said, we could get the very high single thread read performance even with only one node. However, it would be a requirement that the regression tests of performance need to be run repeately on the same hardware for comparison. Thus this is different from the existing regression tests of Lustre. But if we could run the performance tests again and again on the same hardware with the same configuration, we could stop the patches that introduce performance problems from being merged in advance. And that might takes much less time than finding out the bad patches after they are already merged. Do you have any good idea about how to do this? |
| Comment by Jinshan Xiong (Inactive) [ 06/Jul/16 ] |
|
Hi Li Xi, Yes, this is a good idea. Actually we've already had a dedicated cluster for performance test. Our target is to make sure that there is no performance regression for each release. |
| Comment by Gerrit Updater [ 03/Aug/16 ] |
|
Li Xi (lixi@ddn.com) uploaded a new patch: http://review.whamcloud.com/21648 |
| Comment by Gerrit Updater [ 08/Sep/16 ] |
|
Oleg Drokin (oleg.drokin@intel.com) merged in patch http://review.whamcloud.com/5164/ |
| Comment by Li Xi (Inactive) [ 12/Oct/16 ] |
|
Can we reopen this ticket, or should I open a new tickeet for the patch of read bypass? http://review.whamcloud.com/21648 |
| Comment by Jinshan Xiong (Inactive) [ 12/Oct/16 ] |
|
Li Xi: I would rather open a new ticket. Thanks for your work. |