swap: send callback when swap slot is freed

Currently, we have "swap discard" mechanism which sends a discard bio request when we find a free cluster during scan_swap_map(). This callback can come a long time after swap slots are actually freed.

This delay in callback is a great problem when (compressed) RAM [1] is used as a swap device. So, this change adds a callback which is called as soon as a swap slot becomes free. For above mentioned case of swapping over compressed RAM device, this is very useful since we can immediately free memory allocated for this swap page.

This callback does not replace swap discard support. It is called with swap_lock held, so it is meant to trigger action that finishes quickly. However, swap discard is an I/O request and can be used for taking longer actions.

Currently, we have "swap discard" mechanism which sends a discard bio request when we find a free cluster during scan_swap_map(). This callback can come a long time after swap slots are actually freed.

This delay in callback is a great problem when (compressed) RAM [1] is used as a swap device. So, this change adds a callback which is called as soon as a swap slot becomes free. For above mentioned case of swapping over compressed RAM device, this is very useful since we can immediately free memory allocated for this swap page.

This callback does not replace swap discard support. It is called with swap_lock held, so it is meant to trigger action that finishes quickly. However, swap discard is an I/O request and can be used for taking longer actions.

 include/linux/swap.h |    5 +++++
 mm/swapfile.c        |   16 ++++++++++++++++
 2 files changed, 21 insertions(+), 0 deletions(-)

include/linux/swap.h +5 -0

index 7c15334..4cbe3c4 100644
@@ -8,6 +8,7 @@
 #include <linux/memcontrol.h>
 #include <linux/sched.h>
 #include <linux/node.h>
+#include <linux/blkdev.h>
 
 #include <asm/atomic.h>
 #include <asm/page.h>

@@ -20,6 +21,8 @@ struct bio;
 #define SWAP_FLAG_PRIO_MASK	0x7fff
 #define SWAP_FLAG_PRIO_SHIFT	0
 
+typedef void (swap_free_notify_fn) (struct block_device *, unsigned long);
+
 static inline int current_is_kswapd(void)
 {
 	return current->flags & PF_KSWAPD;

@@ -155,6 +158,7 @@ struct swap_info_struct {
 	unsigned int max;
 	unsigned int inuse_pages;
 	unsigned int old_block_size;
+	swap_free_notify_fn *swap_free_notify_fn;
 };
 
 struct swap_list_t {

@@ -295,6 +299,7 @@ extern sector_t swapdev_block(int, pgoff_t);
 extern struct swap_info_struct *get_swap_info_struct(unsigned);
 extern int reuse_swap_page(struct page *);
 extern int try_to_free_swap(struct page *);
+extern void set_swap_free_notify(unsigned, swap_free_notify_fn *);
 struct backing_dev_info;
 
 /* linux/mm/thrash.c */

mm/swapfile.c +3 -0

index 8ffdc0d..aa95fc7 100644
@@ -552,6 +552,20 @@ out:
 	return NULL;
 }
 
+/*
+ * Sets callback for event when swap_map[offset] == 0
+ * i.e. page at this swap offset is no longer used.

mm/swapfile.c +2 -0

 static int swap_entry_free(struct swap_info_struct *p,
 			   swp_entry_t ent, int cache)
 {

@@ -583,6 +597,8 @@ static int swap_entry_free(struct swap_info_struct *p,
 			swap_list.next = p - swap_info;
 		nr_swap_pages++;
 		p->inuse_pages--;
+		if (p->swap_free_notify_fn)
+			p->swap_free_notify_fn(p->bdev, offset);
 	}
 	if (!swap_count(count))
 		mem_cgroup_uncharge_swap(ent);

Currently, we have "swap discard" mechanism which sends a discard bio request when we find a free cluster during scan_swap_map(). This callback can come a long time after swap slots are actually freed.

This delay in callback is a great problem when (compressed) RAM [1] is used as a swap device. So, this change adds a callback which is called as soon as a swap slot becomes free. For above mentioned case of swapping over compressed RAM device, this is very useful since we can immediately free memory allocated for this swap page.

This callback does not replace swap discard support. It is called with swap_lock held, so it is meant to trigger action that finishes quickly. However, swap discard is an I/O request and can be used for taking longer actions.

Links:
[1] http://code.google.com/p/compcache/

Quoted 15 lines · Nitin Gupta

Currently, we have "swap discard" mechanism which sends a discard bio request when we find a free cluster during scan_swap_map(). This callback can come a long time after swap slots are actually freed.

This delay in callback is a great problem when (compressed) RAM [1] is used as a swap device. So, this change adds a callback which is called as soon as a swap slot becomes free. For above mentioned case of swapping over compressed RAM device, this is very useful since we can immediately free memory allocated for this swap page.

This callback does not replace swap discard support. It is called with swap_lock held, so it is meant to trigger action that finishes quickly. However, swap discard is an I/O request and can be used for taking longer actions.

Quoted 2 lines

Links:
[1] http://code.google.com/p/compcache/

Please keep this with compcache for the moment (it has no other users).

I don't share Peter's view that it should be using a more general notifier interface (but I certainly agree with his EXPORT_SYMBOL_GPL).

There better not be others hooking in here at the same time (a BUG_ON could check that): in fact I don't even want you hooking in here where swap_lock is held. Glancing at compcache, I don't see you violating lock hierarchy by that, but it is a worry.

The interface to set the notifier, you currently have it by swap type:
that would better be by bdev, wouldn't it? with a search for the right slot. There's nowhere else in ramzswap.c that you rely on swp_entry_t and page_private(page), let's keep such details out of compcache.

But fundamentally, though I can see how this cutdown communication path is useful to compcache, I'd much rather deal with it by the more general discard route if we can. (I'm one of those still puzzled by the way swap is mixed up with block device in compcache: probably because I never found time to pay attention when you explained.)

You're right to question the utility of the current swap discard placement. That code is almost a year old, written from a position of great ignorance, yet only now do we appear to be on the threshold of having an SSD which really supports TRIM (ah, the Linux ATA TRIM support seems to have gone missing now, but perhaps it's been waiting for a reality to check against too - Willy?).

I won't be surprised if we find that we need to move swap discard support much closer to swap_free (though I know from trying before that it's much messier there): in which case, even if we decided to keep your hotline to compcache (to avoid allocating bios etc.), it would be better placed alongside.

Quoted 2 lines

I don't share Peter's view that it should be using a more general notifier interface (but I certainly agree with his EXPORT_SYMBOL_GPL).

Considering that the callback is made under swap_lock, we should not have an array of callbacks to do. But what if this callback finds other users too? I think we should leave it in its current state till it finds more users and probably add BUG() to make sure callback is not already set.

I will make it EXPORT_SYMBOL_GPL.

Quoted 8 lines · Nitin Gupta

Quoted 2 lines

I don't share Peter's view that it should be using a more general notifier interface (but I certainly agree with his EXPORT_SYMBOL_GPL).

Considering that the callback is made under swap_lock, we should not have an array of callbacks to do. But what if this callback finds other users too? I think we should leave it in its current state till it finds more users and probably add BUG() to make sure callback is not already set.

I will make it EXPORT_SYMBOL_GPL.

If its such a tightly coupled system, then why is compcache a module?

Quoted 3 lines · Hugh Dickins

But fundamentally, though I can see how this cutdown communication path is useful to compcache, I'd much rather deal with it by the more general discard route if we can.

I tried this too -- make discard bio request as soon as a swap slot becomes free (I can send details if you want). However, I could not get it to work.

Also, allocating bio to issue discard I/O request looks like a complete artifact in compcache case.

Quoted 15 lines · Nitin Gupta

Currently, we have "swap discard" mechanism which sends a discard bio request when we find a free cluster during scan_swap_map(). This callback can come a long time after swap slots are actually freed.

This delay in callback is a great problem when (compressed) RAM [1] is used as a swap device. So, this change adds a callback which is called as soon as a swap slot becomes free. For above mentioned case of swapping over compressed RAM device, this is very useful since we can immediately free memory allocated for this swap page.

This callback does not replace swap discard support. It is called with swap_lock held, so it is meant to trigger action that finishes quickly. However, swap discard is an I/O request and can be used for taking longer actions.

Quoted 2 lines

Links:
[1] http://code.google.com/p/compcache/

Please keep this with compcache for the moment (it has no other users).

BTW, last time compcache was not accepted due to lack of performance numbers. Now the project has lot more data for various cases:
http://code.google.com/p/compcache/wiki/Performance
Still need to collect data for worst-case behaviors and such...

Quoted 4 lines · Nitin Gupta

BTW, last time compcache was not accepted due to lack of performance numbers. Now the project has lot more data for various cases:
http://code.google.com/p/compcache/wiki/Performance
Still need to collect data for worst-case behaviors and such...

I checked the link, and it looks like you are positioning compcache as a swap replacement.  If so, then repositioning it as a compressed pre-swap area working together with normal swap-space, if available, may yield a much more powerful system.

compcache is really not really a swap replacement. Its just another swap device that
compresses data and stores it in memory itself. You can have disk based swaps along
with ramzswap (name of block device).

Quoted 5 lines · Nitin Gupta

compcache is really not really a swap replacement. Its just another swap device that
compresses data and stores it in memory itself. You can have disk based swaps along
with ramzswap (name of block device).

So once compcache fills up, it will start to age its contents into normal swap?

Quoted 2 lines · Al Boldi

So once compcache fills up, it will start to age its contents into normal swap?

This is desirable but not yet implemented. For now, if 'backing swap' is used, compcache will forward incompressible pages to the backing swap device. If compcache fills up, kernel will simply send further swap-outs to swap device which comes next in priority.

Quoted 8 lines · Nitin Gupta

Quoted 2 lines · Al Boldi

So once compcache fills up, it will start to age its contents into normal swap?

This is desirable but not yet implemented. For now, if 'backing swap' is used, compcache will forward incompressible pages to the backing swap device. If compcache fills up, kernel will simply send further swap-outs to swap device which comes next in priority.

Ok, this sounds acceptable for now.

The important thing now is to improve performance to a level comparable to a system with normal ssd-swap. Do you have such a comparisson?

Another interresting benchmark would be to use compcache in a maximized configuration, ie. on a system w/ 1024KB Ram assign 960KB for compcache and leave 64KB for the system, and then see how it performs. This may easily pinpoint any bottlenecks compcache has, if any.

But fundamentally, though I can see how this cutdown communication path is useful to compcache, I'd much rather deal with it by the more general discard route if we can. (I'm one of those still puzzled by the way swap is mixed up with block device in compcache: probably because I never found time to pay attention when you explained.)

You're right to question the utility of the current swap discard placement. That code is almost a year old, written from a position of great ignorance, yet only now do we appear to be on the threshold of having an SSD which really supports TRIM (ah, the Linux ATA TRIM support seems to have gone missing now, but perhaps it's been waiting for a reality to check against too - Willy?).

I won't be surprised if we find that we need to move swap discard support much closer to swap_free (though I know from trying before that it's much messier there): in which case, even if we decided to keep your hotline to compcache (to avoid allocating bios etc.), it would be better placed alongside.

So TRIM isn't free, and there's a better way for the drive to find out that the contents of a block no longer matter -- write some new data to it. So if we just swapped a page in, and we're going to swap something else back out again soon, just write it to the same location instead of to a fresh location. You've saved a command, and you've saved the drive some work, plus you've allowed other users to continue accessing the drive in the meantime.

Quoted 7 lines · Matthew Wilcox

So TRIM isn't free, and there's a better way for the drive to find out that the contents of a block no longer matter -- write some new data to it. So if we just swapped a page in, and we're going to swap something else back out again soon, just write it to the same location instead of to a fresh location. You've saved a command, and you've saved the drive some work, plus you've allowed other users to continue accessing the drive in the meantime.

on the other hand, if you then end up swapping the page you read in out again and haven't dirtied it, you now have to actually write it as opposed to just throwing it away (knowing that you already have a copy of it stored on the swap device)

Quoted 6 lines · Hugh Dickins

But fundamentally, though I can see how this cutdown communication path is useful to compcache, I'd much rather deal with it by the more general discard route if we can. (I'm one of those still puzzled by the way swap is mixed up with block device in compcache: probably because I never found time to pay attention when you explained.)

Quoted 6 lines

You're right to question the utility of the current swap discard placement. That code is almost a year old, written from a position of great ignorance, yet only now do we appear to be on the threshold of having an SSD which really supports TRIM (ah, the Linux ATA TRIM support seems to have gone missing now, but perhaps it's been waiting for a reality to check against too - Willy?).

I am indeed waiting for hardware with TRIM support to appear on my desk before resubmitting the TRIM code. It'd also be nice to be able to get some performance numbers.

Quoted 5 lines

I won't be surprised if we find that we need to move swap discard support much closer to swap_free (though I know from trying before that it's much messier there): in which case, even if we decided to keep your hotline to compcache (to avoid allocating bios etc.), it would be better placed alongside.

It turns out there are a lot of tradeoffs involved with discard, and they're different between TRIM and UNMAP.

Let's start with UNMAP. This SCSI command is used by giant arrays. They want to do Thin Provisioning, so allocate physical storage to virtual LUNs on demand, and want to deallocate it when they get an UNMAP command. They allocate storage in large chunks (hundreds of kilobytes at a time). They only care about discards that enable them to free an entire chunk. The vast majority of users *do not care* about these arrays, because they don't have one, and will never be able to afford one. We should ignore the desires of these vendors when designing our software.

Solid State Drives are introducing an ATA command called TRIM. SSDs generally have an intenal mapping layer, and due to their low, low seek penalty, will happily remap blocks anywhere on the flash. They want to know when a block isn't in use any more, so they don't have to copy it around when they want to erase the chunk of storage that it's on. The unfortunate thing about the TRIM command is that it's not NCQ, so all NCQ commands have to finish, then we can send the TRIM command and wait for it to finish, then we can send NCQ commands again.

So TRIM isn't free, and there's a better way for the drive to find out that the contents of a block no longer matter -- write some new data to it. So if we just swapped a page in, and we're going to swap something else back out again soon, just write it to the same location instead of to a fresh location. You've saved a command, and you've saved the drive some work, plus you've allowed other users to continue accessing the drive in the meantime.

I am planning a complete overhaul of the discard work. Users can send down discard requests as frequently as they like. The block layer will cache them, and invalidate them if writes come through. Periodically, the block layer will send down a TRIM or an UNMAP (depending on the underlying device) and get rid of the blocks that have remained unwanted in the interim.

Thoughts on that are welcome.

Quoted 29 lines · Matthew Wilcox

Quoted 6 lines · Hugh Dickins

But fundamentally, though I can see how this cutdown communication path is useful to compcache, I'd much rather deal with it by the more general discard route if we can. (I'm one of those still puzzled by the way swap is mixed up with block device in compcache: probably because I never found time to pay attention when you explained.)

Quoted 7 lines

You're right to question the utility of the current swap discard placement. That code is almost a year old, written from a position of great ignorance, yet only now do we appear to be on the threshold of having an SSD which really supports TRIM (ah, the Linux ATA TRIM support seems to have gone missing now, but perhaps it's been waiting for a reality to check against too - Willy?).

I am indeed waiting for hardware with TRIM support to appear on my desk before resubmitting the TRIM code. It'd also be nice to be able to get some performance numbers.

Quoted 6 lines

I won't be surprised if we find that we need to move swap discard support much closer to swap_free (though I know from trying before that it's much messier there): in which case, even if we decided to keep your hotline to compcache (to avoid allocating bios etc.), it would be better placed alongside.

It turns out there are a lot of tradeoffs involved with discard, and they're different between TRIM and UNMAP.

Quoted 9 lines

Let's start with UNMAP. This SCSI command is used by giant arrays. They want to do Thin Provisioning, so allocate physical storage to virtual LUNs on demand, and want to deallocate it when they get an UNMAP command. They allocate storage in large chunks (hundreds of kilobytes at a time). They only care about discards that enable them to free an entire chunk. The vast majority of users *do not care* about these arrays, because they don't have one, and will never be able to afford one. We should ignore the desires of these vendors when designing our software.

Fundamentally, unmap, trim and write_same do similar things, so realistically they all map to discard in linux.

Ignoring the desires of the enterprise isn't an option, since they are a good base for us. However, they really do need to step up with a useful patch set for discussion that does what they want, so in the interim I'm happy with any proposal that doesn't actively damage what the enterprise wants to do with trim/write_same.

Quoted 10 lines

Solid State Drives are introducing an ATA command called TRIM. SSDs generally have an intenal mapping layer, and due to their low, low seek penalty, will happily remap blocks anywhere on the flash. They want to know when a block isn't in use any more, so they don't have to copy it around when they want to erase the chunk of storage that it's on. The unfortunate thing about the TRIM command is that it's not NCQ, so all NCQ commands have to finish, then we can send the TRIM command and wait for it to finish, then we can send NCQ commands again.

That's a bit of a silly protocol oversight ... I assume there's no way it can be corrected?

Quoted 15 lines

So TRIM isn't free, and there's a better way for the drive to find out that the contents of a block no longer matter -- write some new data to it. So if we just swapped a page in, and we're going to swap something else back out again soon, just write it to the same location instead of to a fresh location. You've saved a command, and you've saved the drive some work, plus you've allowed other users to continue accessing the drive in the meantime.

I am planning a complete overhaul of the discard work. Users can send down discard requests as frequently as they like. The block layer will cache them, and invalidate them if writes come through. Periodically, the block layer will send down a TRIM or an UNMAP (depending on the underlying device) and get rid of the blocks that have remained unwanted in the interim.

Quoted 2 lines

Thoughts on that are welcome.

What you're basically planning is discard accumulation ... it's certainly closer to what the enterprise is looking for, so no objections from me.

James

I am planning a complete overhaul of the discard work. Users can send down discard requests as frequently as they like. The block layer will cache them, and invalidate them if writes come through. Periodically, the block layer will send down a TRIM or an UNMAP (depending on the underlying device) and get rid of the blocks that have remained unwanted in the interim.

Quoted 6 lines · Hugh Dickins

But fundamentally, though I can see how this cutdown communication path is useful to compcache, I'd much rather deal with it by the more general discard route if we can. (I'm one of those still puzzled by the way swap is mixed up with block device in compcache: probably because I never found time to pay attention when you explained.)

Quoted 6 lines

You're right to question the utility of the current swap discard placement. That code is almost a year old, written from a position of great ignorance, yet only now do we appear to be on the threshold of having an SSD which really supports TRIM (ah, the Linux ATA TRIM support seems to have gone missing now, but perhaps it's been waiting for a reality to check against too - Willy?).

I am indeed waiting for hardware with TRIM support to appear on my desk before resubmitting the TRIM code. It'd also be nice to be able to get some performance numbers.

Quoted 5 lines

I won't be surprised if we find that we need to move swap discard support much closer to swap_free (though I know from trying before that it's much messier there): in which case, even if we decided to keep your hotline to compcache (to avoid allocating bios etc.), it would be better placed alongside.

Solid State Drives are introducing an ATA command called TRIM. SSDs generally have an intenal mapping layer, and due to their low, low seek penalty, will happily remap blocks anywhere on the flash. They want to know when a block isn't in use any more, so they don't have to copy it around when they want to erase the chunk of storage that it's on. The unfortunate thing about the TRIM command is that it's not NCQ, so all NCQ commands have to finish, then we can send the TRIM command and wait for it to finish, then we can send NCQ commands again.

So TRIM isn't free, and there's a better way for the drive to find out that the contents of a block no longer matter -- write some new data to it. So if we just swapped a page in, and we're going to swap something else back out again soon, just write it to the same location instead of to a fresh location. You've saved a command, and you've saved the drive some work, plus you've allowed other users to continue accessing the drive in the meantime.

I am planning a complete overhaul of the discard work. Users can send down discard requests as frequently as they like. The block layer will cache them, and invalidate them if writes come through. Periodically, the block layer will send down a TRIM or an UNMAP (depending on the underlying device) and get rid of the blocks that have remained unwanted in the interim.

Quoted 6 lines · Matthew Wilcox

I am planning a complete overhaul of the discard work. Users can send down discard requests as frequently as they like. The block layer will cache them, and invalidate them if writes come through. Periodically, the block layer will send down a TRIM or an UNMAP (depending on the underlying device) and get rid of the blocks that have remained unwanted in the interim.

That is a very good idea. I've tested your original TRIM implementation on my Vertex yesterday and it was awful ;-). The SSD needs hundreds of milliseconds to digest a single TRIM command. And since your implementation sends a TRIM for each extent of each deleted file, the whole system is unusable after a short while.
An optimal solution would be to consolidate the discard requests, bundle them and send them to the drive as infrequent as possible.

Quoted 9 lines · Markus Trippelsdorf

Quoted 7 lines · Matthew Wilcox

I am planning a complete overhaul of the discard work.  Users can send down discard requests as frequently as they like.  The block layer will cache them, and invalidate them if writes come through.  Periodically, the block layer will send down a TRIM or an UNMAP (depending on the underlying device) and get rid of the blocks that have remained unwanted in the interim.

Quoted 8 lines

That is a very good idea. I've tested your original TRIM implementation on my Vertex yesterday and it was awful ;-). The SSD needs hundreds of milliseconds to digest a single TRIM command. And since your implementation
sends a TRIM for each extent of each deleted file, the whole system is unusable after a short while.
An optimal solution would be to consolidate the discard requests, bundle them and send them to the drive as infrequent as possible.

or queue them up and send them when the drive is idle (you would need to keep track to make sure the space isn't re-used)

as an example, if you would consider spinning down a drive you don't hurt performance by sending accumulated trim commands.

David Lang

Quoted 20 lines · On Thu, Aug 13, 2009 at 12:33 PM, <[email protected]> wrote:

Quoted 9 lines · Markus Trippelsdorf

Quoted 7 lines · Matthew Wilcox

I am planning a complete overhaul of the discard work. Users can send down discard requests as frequently as they like. The block layer will cache them, and invalidate them if writes come through. Periodically, the block layer will send down a TRIM or an UNMAP (depending on the underlying device) and get rid of the blocks that have remained unwanted in the interim.

Quoted 8 lines

That is a very good idea. I've tested your original TRIM implementation on my Vertex yesterday and it was awful ;-). The SSD needs hundreds of milliseconds to digest a single TRIM command. And since your implementation
sends a TRIM for each extent of each deleted file, the whole system is unusable after a short while.
An optimal solution would be to consolidate the discard requests, bundle them and send them to the drive as infrequent as possible.

Quoted 7 lines

or queue them up and send them when the drive is idle (you would need to keep track to make sure the space isn't re-used)

as an example, if you would consider spinning down a drive you don't hurt performance by sending accumulated trim commands.

David Lang

An alternate approach is the block layer maintain its own bitmap of used unused sectors / blocks. Unmap commands from the filesystem just cause the bitmap to be updated. No other effect.

(Big unknown: Where will the bitmap live between reboots? Require DM volumes so we can have a dedicated bitmap volume in the mix to store the bitmap to? Maybe on mount, the filesystem has to be scanned to
initially populate the bitmap? Other options?)

Assuming we have a persistent bitmap in place, have a background scanner that kicks in when the cpu / disk is idle. It just continuously scans the bitmap looking for contiguous blocks of unused sectors. Each time it finds one, it sends the largest possible unmap down the block stack and eventually to the device.

When normal cpu / disk activity kicks in, this process goes to sleep.

That way much of the smarts are concentrated in the block layer, not in the filesystem code. And it is being done when the disk is otherwise idle, so you don't have the ncq interference.

Even laptop users should have enough idle cpu available to manage this. Enterprise would get the large discards it wants, and unmentioned in the previous discussion, mdraid gets the large discards it also wants.

ie. If a mdraid raid5/raid6 volume is built of SSDs, it will only be able to discard a full stripe at a time. Otherwise the P=D1 ^ D2 logic is lost.

Another benefit of the above is the code should be extremely safe and testable.

Actually, I think, if we go in-kernel, the discard might be better tied into the block plugging mechanism.  The real test might be no outstanding commands and queue plugged, keep plugged and begin discarding.

Quoted 25 lines · Greg Freemyer

Quoted 17 lines · On Thu, Aug 13, 2009 at 12:33 PM, <[email protected]> wrote:

Quoted 7 lines · Markus Trippelsdorf

Quoted 6 lines · Matthew Wilcox

I am planning a complete overhaul of the discard work. Users can send down discard requests as frequently as they like. The block layer will cache them, and invalidate them if writes come through. Periodically, the block layer will send down a TRIM or an UNMAP (depending on the underlying device) and get rid of the blocks that have remained unwanted in the interim.

Quoted 8 lines

That is a very good idea. I've tested your original TRIM implementation on my Vertex yesterday and it was awful ;-). The SSD needs hundreds of milliseconds to digest a single TRIM command. And since your implementation
sends a TRIM for each extent of each deleted file, the whole system is unusable after a short while.
An optimal solution would be to consolidate the discard requests, bundle them and send them to the drive as infrequent as possible.

Quoted 7 lines

or queue them up and send them when the drive is idle (you would need to keep track to make sure the space isn't re-used)

as an example, if you would consider spinning down a drive you don't hurt performance by sending accumulated trim commands.

David Lang

Quoted 8 lines

An alternate approach is the block layer maintain its own bitmap of used unused sectors / blocks. Unmap commands from the filesystem just cause the bitmap to be updated. No other effect.

(Big unknown: Where will the bitmap live between reboots? Require DM volumes so we can have a dedicated bitmap volume in the mix to store the bitmap to? Maybe on mount, the filesystem has to be scanned to
initially populate the bitmap? Other options?)

I wouldn't really have it live anywhere. Discard is best effort; it's not required for fs integrity. As long as we don't discard an in-use block we're free to do anything else (including forget to discard, rediscard a discarded block etc).

It is theoretically possible to run all of this from user space using the fs mappings, a bit like a defrag command.

Quoted 47 lines · James Bottomley

Quoted 36 lines · Greg Freemyer

Quoted 25 lines · On Thu, Aug 13, 2009 at 12:33 PM, <[email protected]> wrote:

Quoted 11 lines · Markus Trippelsdorf

Quoted 9 lines · Matthew Wilcox

I am planning a complete overhaul of the discard work.  Users can send down discard requests as frequently as they like.  The block layer will
cache them, and invalidate them if writes come through.  Periodically, the block layer will send down a TRIM or an UNMAP (depending on the underlying device) and get rid of the blocks that have remained unwanted
in the interim.

Quoted 10 lines

That is a very good idea. I've tested your original TRIM implementation on
my Vertex yesterday and it was awful ;-). The SSD needs hundreds of milliseconds to digest a single TRIM command. And since your implementation
sends a TRIM for each extent of each deleted file, the whole system is unusable after a short while.
An optimal solution would be to consolidate the discard requests, bundle
them and send them to the drive as infrequent as possible.

Quoted 8 lines

or queue them up and send them when the drive is idle (you would need to keep track to make sure the space isn't re-used)

as an example, if you would consider spinning down a drive you don't hurt
performance by sending accumulated trim commands.

David Lang

Quoted 8 lines

An alternate approach is the block layer maintain its own bitmap of used unused sectors / blocks. Unmap commands from the filesystem just cause the bitmap to be updated.  No other effect.

(Big unknown: Where will the bitmap live between reboots?  Require DM volumes so we can have a dedicated bitmap volume in the mix to store the bitmap to? Maybe on mount, the filesystem has to be scanned to initially populate the bitmap?   Other options?)

Quoted 7 lines

I wouldn't really have it live anywhere.  Discard is best effort; it's not required for fs integrity.  As long as we don't discard an in-use block we're free to do anything else (including forget to discard, rediscard a discarded block etc).

It is theoretically possible to run all of this from user space using the fs mappings, a bit like a defrag command.

..

Already a work-in-progress -- see my wiper.sh script on the hdparm page at sourceforge.  Trimming 50+GB of free space on a 120GB Vertex (over 100 million sectors) takes a *single* TRIM command, and completes in only a couple of seconds.

Cheers

What filesystems does your script support? Running a tool like this in the middle of the night makes a lot of since to me even from the perspective of many / most enterprise users.

ps: I tried to pull wiper.sh straight from sourceforge, but I'm getting some crazy page asking all sorts of questions and not letting me bypass it. I hope sourceforge is broken. The other option is they meant to do this. :(

Quoted 23 lines · On Thu, Aug 13, 2009 at 12:33 PM, <[email protected]> wrote:

Quoted 9 lines · Markus Trippelsdorf

Quoted 7 lines · Matthew Wilcox

I am planning a complete overhaul of the discard work.  Users can send down discard requests as frequently as they like.  The block layer will cache them, and invalidate them if writes come through.  Periodically, the block layer will send down a TRIM or an UNMAP (depending on the underlying device) and get rid of the blocks that have remained unwanted in the interim.

Quoted 8 lines

That is a very good idea. I've tested your original TRIM implementation on my Vertex yesterday and it was awful ;-). The SSD needs hundreds of milliseconds to digest a single TRIM command. And since your implementation
sends a TRIM for each extent of each deleted file, the whole system is unusable after a short while.
An optimal solution would be to consolidate the discard requests, bundle them and send them to the drive as infrequent as possible.

or queue them up and send them when the drive is idle (you would need to keep track to make sure the space isn't re-used)

Quoted 4 lines

as an example, if you would consider spinning down a drive you don't hurt performance by sending accumulated trim commands.

David Lang

An alternate approach is the block layer maintain its own bitmap of used unused sectors / blocks. Unmap commands from the filesystem just cause the bitmap to be updated. No other effect.

(Big unknown: Where will the bitmap live between reboots? Require DM volumes so we can have a dedicated bitmap volume in the mix to store the bitmap to? Maybe on mount, the filesystem has to be scanned to
initially populate the bitmap? Other options?)

Assuming we have a persistent bitmap in place, have a background scanner that kicks in when the cpu / disk is idle. It just continuously scans the bitmap looking for contiguous blocks of unused sectors. Each time it finds one, it sends the largest possible unmap down the block stack and eventually to the device.

When normal cpu / disk activity kicks in, this process goes to sleep.

That way much of the smarts are concentrated in the block layer, not in the filesystem code. And it is being done when the disk is otherwise idle, so you don't have the ncq interference.

Even laptop users should have enough idle cpu available to manage this. Enterprise would get the large discards it wants, and unmentioned in the previous discussion, mdraid gets the large discards it also wants.

ie. If a mdraid raid5/raid6 volume is built of SSDs, it will only be able to discard a full stripe at a time. Otherwise the P=D1 ^ D2 logic is lost.

Another benefit of the above is the code should be extremely safe and testable.

Greg

Quoted 27 lines · Greg Freemyer

Quoted 26 lines · On Thu, Aug 13, 2009 at 12:33 PM, <[email protected]> wrote:

Quoted 10 lines · Markus Trippelsdorf

Quoted 8 lines · Matthew Wilcox

I am planning a complete overhaul of the discard work.  Users can send down discard requests as frequently as they like.  The block layer will cache them, and invalidate them if writes come through.  Periodically, the block layer will send down a TRIM or an UNMAP (depending on the underlying device) and get rid of the blocks that have remained unwanted
in the interim.

Quoted 9 lines

That is a very good idea. I've tested your original TRIM implementation on
my Vertex yesterday and it was awful ;-). The SSD needs hundreds of milliseconds to digest a single TRIM command. And since your implementation
sends a TRIM for each extent of each deleted file, the whole system is unusable after a short while.
An optimal solution would be to consolidate the discard requests, bundle them and send them to the drive as infrequent as possible.

or queue them up and send them when the drive is idle (you would need to keep track to make sure the space isn't re-used)

Quoted 8 lines

Quoted 4 lines

as an example, if you would consider spinning down a drive you don't hurt performance by sending accumulated trim commands.

David Lang

An alternate approach is the block layer maintain its own bitmap of used unused sectors / blocks. Unmap commands from the filesystem just cause the bitmap to be updated.  No other effect.

how does the block layer know what blocks are unused by the filesystem?

or would it be a case of the filesystem generating discard/trim requests to the block layer so that it can maintain it's bitmap, and then the block layer generating the requests to the drive below it?

Perhaps an interface (ioctl, etc) can be added to ask a filesystem to discard all unused blocks in a certain range? (That is, have the filesystem validate the request under any necessary locks before passing it to the block IO layer)

Bryan Donlan wrote:
..

Quoted 5 lines

Perhaps an interface (ioctl, etc) can be added to ask a filesystem to discard all unused blocks in a certain range? (That is, have the filesystem validate the request under any necessary locks before passing it to the block IO layer)

..

While possibly TRIM-specific, this approach has the lowest overhead and probably the greatest gain-for-pain ratio.

But it may not be as nice for enterprise (?).

On the Indilinx-based SSDs (eg. OCZ Vertex), TRIM seems to trigger an internal garbage-collection/erase cycle.  As such, the drive really prefers a few LARGE trim lists, rather than many smaller ones.

Here's some information that a vendor has observed from the Win7 use of TRIM:

Quoted 11 lines

TRIM command is sent:
-       About 2/3 of partition is filled up, when file is deleted. (I am not talking about send file to trash bin.)
-       In the above case, when trash bin gets emptied.
-       In the above case, when partition is deleted.

TRIM command is not sent:-
-       When file is moved to trash bin
-       When partition is formatted. (Both quick and full format)
-       When empty partition is deleted
-       When file is deleted while there is big remaining free space

..

His words, not mine.  But the idea seems to be to batch them in large chunks.

My wiper.sh "trim script" is packaged with the latest hdparm (currently 9.24)
on sourceforge, for those who want to try this stuff for real.  No special kernel support is required to use it.

Cheers

Mark
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Sooner is better than waiting to coalesce. The longer an LBA is inactive, the better for any management scheme. If you wait until it's reused, you might as well forgo the advantages of TRIM/UNMAP. If a the controller wants to coalesce, let it coalesce.

Quoted 4 lines · Chris Worley

Sooner is better than waiting to coalesce.  The longer an LBA is inactive, the better for any management scheme.  If you wait until it's reused, you might as well forgo the advantages of TRIM/UNMAP.  If a the controller wants to coalesce, let it coalesce.

I'm sorry, you're wrong.  There is a tradeoff point, and it's different for each drive model.  Sending down a steady stream of tiny TRIMs is going to give terrible performance.

--
Matthew Wilcox                          Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours.  We can't possibly take such a retrograde step."

Quoted 9 lines · Matthew Wilcox

Quoted 4 lines · Chris Worley

Sooner is better than waiting to coalesce.  The longer an LBA is inactive, the better for any management scheme.  If you wait until it's reused, you might as well forgo the advantages of TRIM/UNMAP.  If a the controller wants to coalesce, let it coalesce.

I'm sorry, you're wrong.  There is a tradeoff point, and it's different for each drive model.  Sending down a steady stream of tiny TRIMs is going to give terrible performance.

Sounds like you might be using junk for a device?

For junk, a little coalescing may be warranted... like in the I/O schedular, but no more than 100usecs wait before posting, or then you effect high performing devices too.

Chris

Quoted 17 lines · Chris Worley

Quoted 9 lines · Matthew Wilcox

Quoted 4 lines · Chris Worley

Sooner is better than waiting to coalesce.  The longer an LBA is inactive, the better for any management scheme.  If you wait until it's reused, you might as well forgo the advantages of TRIM/UNMAP.  If a the controller wants to coalesce, let it coalesce.

I'm sorry, you're wrong.  There is a tradeoff point, and it's different for each drive model.  Sending down a steady stream of tiny TRIMs is going to give terrible performance.

Sounds like you might be using junk for a device?

For junk, a little coalescing may be warranted... like in the I/O schedular, but no more than 100usecs wait before posting, or then you effect high performing devices too.

Quoted 1 line

Chris

Why?

AIUI, on every write a high performing device allocates a new erase block from its free lists, writes to it, and puts the now unused erase block on the free list.

 That erase block becomes available for reuse
some milliseconds later.

As long as the SSD has enough free erase blocks to work with I see no disadvantage in delaying a discard by minutes, hours or days in most cases.  The exception is when the filesystem is almost full and the SSD is short of erase blocks to work with.

In that case it will want to get as many free erase blocks as it can as fast as it can get them.

Greg

Quoted 20 lines · Greg Freemyer

Quoted 18 lines · Chris Worley

Quoted 9 lines · Matthew Wilcox

Quoted 4 lines · Chris Worley

Sooner is better than waiting to coalesce.  The longer an LBA is inactive, the better for any management scheme.  If you wait until it's reused, you might as well forgo the advantages of TRIM/UNMAP.  If a the controller wants to coalesce, let it coalesce.

I'm sorry, you're wrong.  There is a tradeoff point, and it's different for each drive model.  Sending down a steady stream of tiny TRIMs is going to give terrible performance.

Sounds like you might be using junk for a device?

For junk, a little coalescing may be warranted... like in the I/O schedular, but no more than 100usecs wait before posting, or then you effect high performing devices too.

Chris

Quoted 5 lines

Why?

AIUI, on every write a high performing device allocates a new erase block from its free lists, writes to it, and puts the now unused erase block on the free list.

So erase blocks are 512 bytes (if I write 512 bytes, an erase block is now freed)?  Not true.

So erase blocks are 512 bytes (if I write 512 bytes, an erase block is now freed)? Not true.

Chris Worley wrote:
..

Quoted 3 lines

So erase blocks are 512 bytes (if I write 512 bytes, an erase block is now freed)?  Not true.

..

No, erase blocks are typically 512 KILO-bytes, or 1024 sectors. Logical write blocks are only 512 bytes,

but most drives out there
now actually use 4096 bytes as the native internal write size.

Lots of issues there.

The only existing "in the wild" TRIM-capable SSDs today all incur large overheads from TRIM

--> they seem to run a garbage-collection
and erase cycle for each TRIM command, typically taking 100s of milliseconds regardless of the amount being trimmed.

So it makes send to gather small TRIMs into single larger TRIMs.

But I think, even better, is to just not bother with the bookkeeping, and instead have the filesystem periodically just issue a TRIM for all free blocks within a block group, cycling through the block groups one by one over time.

That's how I'd like it to work on my own machine here. Server/enterprise users very likely want something different.

Pluggable architecture, anyone?  :)

The OS should not assume a dumb algorithm on the part of the drive.

Quoted 9 lines · Matthew Wilcox

Quoted 4 lines · Chris Worley

Sooner is better than waiting to coalesce. The longer an LBA is inactive, the better for any management scheme. If you wait until it's reused, you might as well forgo the advantages of TRIM/UNMAP. If a the controller wants to coalesce, let it coalesce.

I'm sorry, you're wrong. There is a tradeoff point, and it's different for each drive model. Sending down a steady stream of tiny TRIMs is going to give terrible performance.

Sounds like you might be using junk for a device?

For junk, a little coalescing may be warranted... like in the I/O schedular, but no more than 100usecs wait before posting, or then you effect high performing devices too.

This means you have to drain the outstanding NCQ commands (stalling the
device) before you can send a TRIM. If we do this for every discard,
the performance impact will be pretty devastating, hence the need to coalesce. It's nothing really to do with device characteristics, it's an ATA protocol problem.

Quoted 6 lines · James Bottomley

This means you have to drain the outstanding NCQ commands (stalling the
device) before you can send a TRIM. If we do this for every discard,
the performance impact will be pretty devastating, hence the need to coalesce. It's nothing really to do with device characteristics, it's an ATA protocol problem.

..

I don't think that's really much of an issue -- we already have to do that for cache-flushes whenever barriers are enabled. Yes it costs, but not too much.

That's not really what the enterprise is saying about flush barriers. True, not all the performance problems are NCQ queue drain, but for a steady workload they are significant.

***begin rant***

I have not seen any analysis of the benefit and cost to the end user of the TRIM or array UNMAP. We now see that TRIM as implemented by some (all?) SSDs will come at high cost. The cost is all born by the host. Do we get any benefit, or is it all for the device vendor. And when we subtract the cost from the benefit, does the user actually benefit and how?

I'm tired of working around shit storage products and broken device protocols from the "T" committees. I suggest we just add a "white list" of devices that handle the discard fast and without us needing NCQ queue drain. Then only send TRIM to devices that are on the white list and throw the others away in the block device layer.

Quoted 9 lines · Mark Lord

Quoted 6 lines · James Bottomley

This means you have to drain the outstanding NCQ commands (stalling the
device) before you can send a TRIM. If we do this for every discard,
the performance impact will be pretty devastating, hence the need to coalesce. It's nothing really to do with device characteristics, it's an ATA protocol problem.

..

Quoted 3 lines

I don't think that's really much of an issue -- we already have to do that for cache-flushes whenever barriers are enabled. Yes it costs, but not too much.

That's not really what the enterprise is saying about flush barriers. True, not all the performance problems are NCQ queue drain, but for a steady workload they are significant.

Flush barriers are nightmare for more than enterprise. You drive basically goes for a hike for a bit which trashes interactivity as well. If the device can't do trim and the like without a drain I don't see much point doing it at all, except maybe to wait for idle devices and run a filesystem managed background 'strimmer' thread to just weed out now idle blocks that have stayed idle - eg by adding an inode of all the deleted untrimmed blocks and giving it an irregular empty ?

Quoted 10 lines · On Sat, 15 Aug 2009 08:55:17 -0500 James Bottomley <[email protected]>…

Quoted 9 lines · Mark Lord

Quoted 6 lines · James Bottomley

This means you have to drain the outstanding NCQ commands
(stalling the device) before you can send a TRIM. If we do
this for every discard, the performance impact will be pretty devastating, hence the need to coalesce. It's nothing really to do with device characteristics, it's an ATA protocol problem.

..

Quoted 7 lines

Quoted 3 lines

I don't think that's really much of an issue -- we already have to do that for cache-flushes whenever barriers are enabled. Yes it costs, but not too much.

That's not really what the enterprise is saying about flush barriers. True, not all the performance problems are NCQ queue drain, but for a steady workload they are significant.

Flush barriers are nightmare for more than enterprise. You drive basically goes for a hike for a bit which trashes interactivity as well. If the device can't do trim and the like without a drain I don't see much point doing it at all, except maybe to wait for idle devices and run a filesystem managed background 'strimmer' thread to just weed out now idle blocks that have stayed idle - eg by adding an inode of all the deleted untrimmed blocks and giving it an irregular empty ?

trim is mostly for ssd's though, and those tend to not have the "goes for a hike" behavior as much......

Mark Lord has claimed that the currently shipping SSD's take "hundreds of milliseconds" for a TRIM, command.

As you can see, we're now into the 100 millisecond range for successive TRIM-followed-by-TRIM commands.

Those are all for single extents. I will follow-up with a small amount of similar data for TRIMs with multiple extents.

As you can see, we're now into the 100 millisecond range for successive TRIM-followed-by-TRIM commands.

Those are all for single extents. I will follow-up with a small amount of similar data for TRIMs with multiple extents.

Mark Lord wrote:
..

Quoted 5 lines

As you can see, we're now into the 100 millisecond range for successive TRIM-followed-by-TRIM commands.

Those are all for single extents. I will follow-up with a small amount of similar data for TRIMs with multiple extents.

..

Here's the exact same TRIM ranges, but issued with *two* extents per TRIM command, and again *without* the "sleep 1" between them:

Beginning TRIM operations..
Trimming 2 free extents encompassing 686 sectors (0 MB) Trimming 2 free extents encompassing 236 sectors (0 MB) Trimming 2 free extents encompassing 2186 sectors (1 MB) Trimming 2 free extents encompassing 2206 sectors (1 MB) Trimming 2 free extents encompassing 1494 sectors (1 MB) Trimming 2 free extents encompassing 1086 sectors (1 MB) Trimming 2 free extents encompassing 1658 sectors (1 MB) Trimming 2 free extents encompassing 14250 sectors (7 MB) Done.

[ 1528.761626] ata_qc_issue: ATA_CMD_DSM starting
[ 1528.761825] trim_completed: ATA_CMD_DSM took 419952 cycles
[ 1528.807158] ata_qc_issue: ATA_CMD_DSM starting
[ 1528.919035] trim_completed: ATA_CMD_DSM took 241772908 cycles
[ 1528.956048] ata_qc_issue: ATA_CMD_DSM starting
[ 1529.068536] trim_completed: ATA_CMD_DSM took 243085505 cycles
[ 1529.156661] ata_qc_issue: ATA_CMD_DSM starting
[ 1529.266377] trim_completed: ATA_CMD_DSM took 237098927 cycles
[ 1529.367212] ata_qc_issue: ATA_CMD_DSM starting
[ 1529.464676] trim_completed: ATA_CMD_DSM took 210619370 cycles
[ 1529.518619] ata_qc_issue: ATA_CMD_DSM starting
[ 1529.630444] trim_completed: ATA_CMD_DSM took 241654712 cycles
[ 1529.739335] ata_qc_issue: ATA_CMD_DSM starting
[ 1529.829826] trim_completed: ATA_CMD_DSM took 195545233 cycles
[ 1529.958442] ata_qc_issue: ATA_CMD_DSM starting
[ 1530.028356] trim_completed: ATA_CMD_DSM took 151077251 cycles

Next, with *four* extents per TRIM:

Beginning TRIM operations..
Trimming 4 free extents encompassing 922 sectors (0 MB) Trimming 4 free extents encompassing 4392 sectors (2 MB) Trimming 4 free extents encompassing 2580 sectors (1 MB) Trimming 4 free extents encompassing 15908 sectors (8 MB) Done.

[ 1728.923119] ata_qc_issue: ATA_CMD_DSM starting
[ 1728.923343] trim_completed: ATA_CMD_DSM took 460590 cycles
[ 1728.975082] ata_qc_issue: ATA_CMD_DSM starting
[ 1729.087266] trim_completed: ATA_CMD_DSM took 242429200 cycles
[ 1729.170167] ata_qc_issue: ATA_CMD_DSM starting
[ 1729.282718] trim_completed: ATA_CMD_DSM took 243229428 cycles
[ 1729.382328] ata_qc_issue: ATA_CMD_DSM starting
[ 1729.481364] trim_completed: ATA_CMD_DSM took 214012942 cycles

And with *eight* extents per TRIM:
Beginning TRIM operations..
Trimming 8 free extents encompassing 5314 sectors (3 MB) Trimming 8 free extents encompassing 18488 sectors (9 MB) Done.

[ 1788.289669] ata_qc_issue: ATA_CMD_DSM starting
[ 1788.290247] trim_completed: ATA_CMD_DSM took 1228539 cycles
[ 1788.327223] ata_qc_issue: ATA_CMD_DSM starting
[ 1788.440490] trim_completed: ATA_CMD_DSM took 244773243 cycles

And finally, with everything in a single TRIM:

Beginning TRIM operations..
Trimming 16 free extents encompassing 23802 sectors (12 MB) Done.

[ 1841.561147] ata_qc_issue: ATA_CMD_DSM starting
[ 1841.563217] trim_completed: ATA_CMD_DSM took 4458480 cycles

Notice how the first TRIM of each group above shows an artificially short completion time, because the firmware seems to return "done" before it's really done. Subsequent TRIMs seem to have to wait for the previous one to really complete, and thus give more reliable timing data for our purposes.

I assume that it really is artificial, rather than the device really being ready for another operation (other than another TRIM). I lack the hardware, but the test would be the time to complete a read, trim and read, and two trim and read operations. Just my thought that the TRIM in progress may only block the next TRIM, rather than other operations.

Quoted 2 lines · Bill Davidsen

I assume that it really is artificial, rather than the device really being ready for another operation (other than another TRIM). I lack the hardware, but the test would be the time to complete a read, trim and read, and two trim and read operations. Just my thought that the TRIM in progress may only block the next TRIM, rather than other operations.

I don't know his test sequence but READ is not the likely command before and after TRIM unless we are talking about TRIM being issued only in delayed host garbage collection. Filesystems send WRITES during delete.

Quoted 8 lines · jim owens

Quoted 2 lines · Bill Davidsen

I assume that it really is artificial, rather than the device really being ready for another operation (other than another TRIM). I lack the hardware, but the test would be the time to complete a read, trim and read, and two trim and read operations. Just my thought that the TRIM in progress may only block the next TRIM, rather than other operations.

I don't know his test sequence but READ is not the likely command before and after TRIM unless we are talking about TRIM being issued only in delayed host garbage collection. Filesystems send WRITES during delete.

My idea is to test using a command which will definitely not need to prepare the media before completion, thus read. If TRIM doesn't block reads, then NCQ may allow reads to take place. Because of buffering slow reads hurt more than slow writes in terms of user perception.

As you can see, we're now into the 100 millisecond range for successive TRIM-followed-by-TRIM commands.

Those are all for single extents. I will follow-up with a small amount of similar data for TRIMs with multiple extents.

As you can see, we're now into the 100 millisecond range for successive TRIM-followed-by-TRIM commands.

Those are all for single extents. I will follow-up with a small amount of similar data for TRIMs with multiple extents.

Mark Lord has claimed that the currently shipping SSD's take "hundreds of milliseconds" for a TRIM, command.

Mark Lord has claimed that the currently shipping SSD's take "hundreds of milliseconds" for a TRIM, command.

Mark Lord has claimed that the currently shipping SSD's take "hundreds of milliseconds" for a TRIM, command.

Quoted 21 lines · On Sun, 16 Aug 2009 15:05:30 +0100 Alan Cox <[email protected]> wrote:

Quoted 10 lines · On Sat, 15 Aug 2009 08:55:17 -0500 James Bottomley <[email protected]>…

Quoted 9 lines · Mark Lord

Quoted 6 lines · James Bottomley

This means you have to drain the outstanding NCQ commands
(stalling the device) before you can send a TRIM. If we do
this for every discard, the performance impact will be pretty devastating, hence the need to coalesce. It's nothing really to do with device characteristics, it's an ATA protocol problem.

..

Quoted 7 lines

Quoted 3 lines

I don't think that's really much of an issue -- we already have to do that for cache-flushes whenever barriers are enabled. Yes it costs, but not too much.

That's not really what the enterprise is saying about flush barriers. True, not all the performance problems are NCQ queue drain, but for a steady workload they are significant.

Quoted 8 lines

Flush barriers are nightmare for more than enterprise. You drive basically goes for a hike for a bit which trashes interactivity as well. If the device can't do trim and the like without a drain I don't see much point doing it at all, except maybe to wait for idle devices and run a filesystem managed background 'strimmer' thread to just weed out now idle blocks that have stayed idle - eg by adding an inode of all the deleted untrimmed blocks and giving it an irregular empty ?

trim is mostly for ssd's though, and those tend to not have the "goes for a hike" behavior as much......

I wonder if it's worse to batch stuff up, because then the trim itself gets bigger and might take longer.....

For SSDs, the FTL has to have a separate operation: erase. Now, one could see the correct implementation simply moving the sectors from the in-use list to the to be cleaned list and still do the cleaning in the
background: that would be constant cost (but, again, likely expensive). Of course, if SSD vendors decided to erase on the spot when seeing TRIM, this wouldn't be true ...

Quoted 7 lines · James Bottomley

For SSDs, the FTL has to have a separate operation: erase. Now, one could see the correct implementation simply moving the sectors from the in-use list to the to be cleaned list and still do the cleaning in the
background: that would be constant cost (but, again, likely expensive). Of course, if SSD vendors decided to erase on the spot when seeing TRIM, this wouldn't be true ...

..

The SSDs based upon the Indilinx Barefoot controller appear to do the erase on the spot, along with a fair amount of garbage collection.

The overhead does vary by size of the TRIM operation (number of sectors and extents), but even a single-sector TRIM has very high overhead.

Samsung also now has SSDs at retail with TRIM.
I don't have one of those here.

Heh, OS writers not having access to the devices is about par for the current course.

Quoted 3 lines · James Bottomley

Heh, OS writers not having access to the devices is about par for the current course.

..

Pity the Linux Foundation doesn't simply step in and supply hardware to us for new tech like this. Cheap for them, expensive for folks like me.

Quoted 10 lines · Mark Lord

Quoted 3 lines · James Bottomley

Heh, OS writers not having access to the devices is about par for the current course.

..

Pity the Linux Foundation doesn't simply step in and supply hardware to us for new tech like this. Cheap for them, expensive for folks like me.

Um, to give a developer a selection of manufacturers' SSDs at retail prices, you're talking several thousand dollars ... in these lean times, that would be two or three developers not getting travel sponsorship per chosen SSD recipient. It's not a worthwhile tradeoff.

The best the LF can likely do is try to explain to the manufacturers that handing out samples at linux conferences (like plumbers) is in their own interests. It can also manage the handout if necessary through its HW lending library.

All,

Seems like the high-level wrap-up of all this is:

There are hopes that highly efficient SSDs will appear on the market that can leverage a passthru non-coalescing discard feature. And that a whitelist should be created to allow those SSDs to see discards intermixed with the rest of the data i/o.

For the other known cases:

SSDs that meet the ata-8 spec, but don't exceed it Enterprise SCSI

mdraid with SSD storage used to build raid5 / raid6 arrays

Non-coalescing is believed detrimental,

but a regular flushing of the
unused blocks/sectors via a tool like Mark Lord has written should be acceptable.

Mark, I don't believe your tool really addresses the mdraid situation, do you agree. ie. Since your bypassing most of the block stack, mdraid has no way of snooping on / adjusting the discards you are sending out.

Thus the 2 solutions that have been worked on already seem to address the needs of everything but mdraid.

Also, there has been no discussion of dm based volumes. (ie LVM2 based volumes)

For mdraid or dm it seems we need to enhance Mark's script to pass the trim commands through the full block stack. Mark, please cmiiw

Greg

Quoted 4 lines · Greg Freemyer

All,

Seems like the high-level wrap-up of all this is:

Quoted 4 lines

There are hopes that highly efficient SSDs will appear on the market that can leverage a passthru non-coalescing discard feature.  And that a whitelist should be created to allow those SSDs to see discards intermixed with the rest of the data i/o.

That's not my conclusion.  Mine was the NCQ drain would still be detremental to interleaved trim even if the drive could do it for zero cost.

Quoted 4 lines

For the other known cases:

SSDs that meet the ata-8 spec, but don't exceed it Enterprise SCSI

No, SCSI will do WRITE_SAME/UNMAP as currently drafted in SBC3

Quoted 3 lines

mdraid with SSD storage used to build raid5 / raid6 arrays

Non-coalescing is believed detrimental,

It is?  Why?

Quoted 9 lines

 but a regular flushing of the
unused blocks/sectors via a tool like Mark Lord has written should be acceptable.

Mark, I don't believe your tool really addresses the mdraid situation, do you agree.  ie. Since your bypassing most of the block stack, mdraid has no way of snooping on / adjusting the discards you are sending out.

Quoted 2 lines

Thus the 2 solutions that have been worked on already seem to address the needs of everything but mdraid.

I count three:  Mark Lord script via SG_IO.  hch enhanced script via XFS_TRIM and willy current discard inline which he's considering coalescing for.

James

Quoted 5 lines · James Bottomley

Quoted 4 lines · Greg Freemyer

All,

Seems like the high-level wrap-up of all this is:

Quoted 8 lines

Quoted 4 lines

There are hopes that highly efficient SSDs will appear on the market that can leverage a passthru non-coalescing discard feature. And that a whitelist should be created to allow those SSDs to see discards intermixed with the rest of the data i/o.

That's not my conclusion. Mine was the NCQ drain would still be detremental to interleaved trim even if the drive could do it for zero cost.

Maybe I misunderstood Jim Owens previous comment that designing for devices that only meet the spec. was not his / Linus'es preference.

Instead they want to have a whitelist enabled list of drives that support trim / ncq without having to drain the queue.

I just re-read his post and he did not explicitly say that, so maybe I'm mis-representing it.

Quoted 7 lines

Quoted 4 lines

For the other known cases:

SSDs that meet the ata-8 spec, but don't exceed it Enterprise SCSI

No, SCSI will do WRITE_SAME/UNMAP as currently drafted in SBC3

Quoted 5 lines

Quoted 3 lines

mdraid with SSD storage used to build raid5 / raid6 arrays

Non-coalescing is believed detrimental,

It is? Why?

For the only compliant SSD in the wild, Mark has shown it to be true via testing.

For Enterprise SCSI, I thought you said a coalescing solution is preferred. (I took that to mean non-coalescing is detremental. Not true?).

For mdraid, if the trims are not coalesced mdraid will have to either ignore them, or coalesce them themselves. Having them come in bigger discard ranges is clearly better. (ie. At least the size of a stripe, so it can adjust the start / end sector to a stripe boundary.)

Quoted 12 lines

Quoted 11 lines

but a regular flushing of the
unused blocks/sectors via a tool like Mark Lord has written should be acceptable.

Mark, I don't believe your tool really addresses the mdraid situation, do you agree. ie. Since your bypassing most of the block stack, mdraid has no way of snooping on / adjusting the discards you are sending out.

Thus the 2 solutions that have been worked on already seem to address the needs of everything but mdraid.

Quoted 3 lines

I count three: Mark Lord script via SG_IO. hch enhanced script via XFS_TRIM and willy current discard inline which he's considering coalescing for.

I missed XFS_TRIM somehow. What benefit does XFS_TRIM provide at a high level? Is it part of the realtime delete file process, or an after the fact scanner?

Quoted 2 lines · Greg Freemyer

Quoted 1 line · James Bottomley

On Mon, 2009-08-17 at 13:08 -0400, Greg Freemyer wrote:

Quoted 4 lines

Quoted 2 lines

Quoted 1 line

Non-coalescing is believed detrimental,

It is? Why?

For the only compliant SSD in the wild, Mark has shown it to be true via testing.

He only said larger trims take longer. As I said previously, if it's a X+nY relationship, then we still benefit from accumulation up to some value of n.

Quoted 3 lines · James Bottomley

Quoted 2 lines · Greg Freemyer

Quoted 1 line · James Bottomley

On Mon, 2009-08-17 at 13:08 -0400, Greg Freemyer wrote:

..

Quoted 5 lines

Quoted 4 lines

Quoted 2 lines

Quoted 1 line

Non-coalescing is believed detrimental,

It is? Why?

For the only compliant SSD in the wild, Mark has shown it to be true via testing.

Quoted 3 lines

He only said larger trims take longer. As I said previously, if it's a X+nY relationship, then we still benefit from accumulation up to some value of n.

..

Err, what I said was, "rm -rf /usr/src/linux" takes over half an hour with uncoalesced TRIM, and only a scant few seconds in total *with* coalesced TRIM.

Mark, I don't believe your tool really addresses the mdraid situation, do you agree. ie. Since your bypassing most of the block stack, mdraid has no way of snooping on / adjusting the discards you are sending out.

However, the enterprise has been doing UNMAP for a while, so we can draw inferences from them since the SSD FTL will operate similarly. For them, UNMAP is the same cost in terms of time regardless of the number of extents. The reason is that it's moving the blocks from the global in use list to the global free list. Part of the problem is that this involves locking and quiescing, so UNMAP ends up being quite expensive to the array but constant in terms of cost (hence they want as few unmaps for as many sectors as possible).

Quoted 8 lines · James Bottomley

However, the enterprise has been doing UNMAP for a while, so we can draw inferences from them since the SSD FTL will operate similarly. For them, UNMAP is the same cost in terms of time regardless of the number of extents. The reason is that it's moving the blocks from the global in use list to the global free list. Part of the problem is that this involves locking and quiescing, so UNMAP ends up being quite expensive to the array but constant in terms of cost (hence they want as few unmaps for as many sectors as possible).

How are they doing the unmaps? Using something similar to Mark's wiper script and using SG_IO? Because right now we do not actually implement UNMAP support in the kernel. I'd really love to test the XFS batched discard support with a real UNMAP implementation.

Quoted 8 lines · James Bottomley

However, the enterprise has been doing UNMAP for a while, so we can draw inferences from them since the SSD FTL will operate similarly. For them, UNMAP is the same cost in terms of time regardless of the number of extents. The reason is that it's moving the blocks from the global in use list to the global free list. Part of the problem is that this involves locking and quiescing, so UNMAP ends up being quite expensive to the array but constant in terms of cost (hence they want as few unmaps for as many sectors as possible).

How are they doing the unmaps? Using something similar to Mark's wiper script and using SG_IO? Because right now we do not actually implement UNMAP support in the kernel. I'd really love to test the XFS batched discard support with a real UNMAP implementation.

The testing was initially done to see if the initial maximal discard proposal from LSF09 was a viable approach (which it wasn't given the time taken to UNMAP).

Quoted 3 lines · James Bottomley

The testing was initially done to see if the initial maximal discard proposal from LSF09 was a viable approach (which it wasn't given the time taken to UNMAP).

It would be nice if that feedback could be made public instead of it leaking out in dribs and drabs like this.

Quoted 7 lines · Matthew Wilcox

Quoted 3 lines · James Bottomley

The testing was initially done to see if the initial maximal discard proposal from LSF09 was a viable approach (which it wasn't given the time taken to UNMAP).

It would be nice if that feedback could be made public instead of it leaking out in dribs and drabs like this.

Yeah, I don't remember hearing about anything like this either.

Well, yes and no ... a lot of SSDs don't actually implement NCQ, so the impact to them will be less ... although I think enterprise class SSDs do implement NCQ.

Quoted 4 lines

Well, yes and no ... a lot of SSDs don't actually implement NCQ, so the impact to them will be less ... although I think enterprise class SSDs do implement NCQ.

Really? Which SSDs don't implement NCQ?

Quoted 4 lines

Well, yes and no ... a lot of SSDs don't actually implement NCQ, so the impact to them will be less ... although I think enterprise class SSDs do implement NCQ.

Really? Which SSDs don't implement NCQ?

Quoted 5 lines · Roland Dreier

Quoted 3 lines

Well, yes and no ... a lot of SSDs don't actually implement NCQ, so the impact to them will be less ... although I think enterprise class SSDs do implement NCQ.

Really? Which SSDs don't implement NCQ?

The Intel X25-M was the first SSD to implement NCQ. The OCZ Core V2 advertised NCQ with a queue depth of 1, but even that was buggy, so Linux has a black list for the that SSD:

http://markmail.org/message/jvjpmcdqjwrmyl4w

As far as I know, all of the SSD's using the crappy JMicron JMF602 controllers don't support NCQ in any real way, which would includes most of the reasonably priced SSD's up until first half of this year. (The OCZ Summit SSD, which uses the Indilnx controller is an exception to this statement, but it's more expensive that the JMF602 based SSD's, although less expensive than the Intel SSD.)

JMicron is trying to seek redemption with their JMF612 controllers, which were announced at the end of May of this year, and those controllers do support NCQ, and are claimed to not to have the disatrous small write latency problem of their '602 bretheren. I'm not aware of any products using the JMF612 yet, though. (According to reports the '612 controllers weren't going to hit mass production until July, so hopefully later this fall we'll start seeing products using the new JMicron controller.)

Quoted 5 lines · Roland Dreier

Quoted 3 lines

Well, yes and no ... a lot of SSDs don't actually implement NCQ, so the impact to them will be less ... although I think enterprise class SSDs do implement NCQ.

Really? Which SSDs don't implement NCQ?

The Intel X25-M was the first SSD to implement NCQ. The OCZ Core V2 advertised NCQ with a queue depth of 1, but even that was buggy, so Linux has a black list for the that SSD:

http://markmail.org/message/jvjpmcdqjwrmyl4w

As far as I know, all of the SSD's using the crappy JMicron JMF602 controllers don't support NCQ in any real way, which would includes most of the reasonably priced SSD's up until first half of this year. (The OCZ Summit SSD, which uses the Indilnx controller is an exception to this statement, but it's more expensive that the JMF602 based SSD's, although less expensive than the Intel SSD.)

JMicron is trying to seek redemption with their JMF612 controllers, which were announced at the end of May of this year, and those controllers do support NCQ, and are claimed to not to have the disatrous small write latency problem of their '602 bretheren. I'm not aware of any products using the JMF612 yet, though. (According to reports the '612 controllers weren't going to hit mass production until July, so hopefully later this fall we'll start seeing products using the new JMicron controller.)

Quoted 5 lines · Roland Dreier

Quoted 3 lines

Well, yes and no ... a lot of SSDs don't actually implement NCQ, so the impact to them will be less ... although I think enterprise class SSDs do implement NCQ.

Really? Which SSDs don't implement NCQ?

The Intel X25-M was the first SSD to implement NCQ. The OCZ Core V2 advertised NCQ with a queue depth of 1, but even that was buggy, so Linux has a black list for the that SSD:

http://markmail.org/message/jvjpmcdqjwrmyl4w

As far as I know, all of the SSD's using the crappy JMicron JMF602 controllers don't support NCQ in any real way, which would includes most of the reasonably priced SSD's up until first half of this year. (The OCZ Summit SSD, which uses the Indilnx controller is an exception to this statement, but it's more expensive that the JMF602 based SSD's, although less expensive than the Intel SSD.)

JMicron is trying to seek redemption with their JMF612 controllers, which were announced at the end of May of this year, and those controllers do support NCQ, and are claimed to not to have the disatrous small write latency problem of their '602 bretheren. I'm not aware of any products using the JMF612 yet, though. (According to reports the '612 controllers weren't going to hit mass production until July, so hopefully later this fall we'll start seeing products using the new JMicron controller.)

Quoted 5 lines · Roland Dreier

Quoted 3 lines

Well, yes and no ... a lot of SSDs don't actually implement NCQ, so the impact to them will be less ... although I think enterprise class SSDs do implement NCQ.

Really? Which SSDs don't implement NCQ?

The Intel X25-M was the first SSD to implement NCQ. The OCZ Core V2 advertised NCQ with a queue depth of 1, but even that was buggy, so Linux has a black list for the that SSD:

http://markmail.org/message/jvjpmcdqjwrmyl4w

As far as I know, all of the SSD's using the crappy JMicron JMF602 controllers don't support NCQ in any real way, which would includes most of the reasonably priced SSD's up until first half of this year. (The OCZ Summit SSD, which uses the Indilnx controller is an exception to this statement, but it's more expensive that the JMF602 based SSD's, although less expensive than the Intel SSD.)

JMicron is trying to seek redemption with their JMF612 controllers, which were announced at the end of May of this year, and those controllers do support NCQ, and are claimed to not to have the disatrous small write latency problem of their '602 bretheren. I'm not aware of any products using the JMF612 yet, though. (According to reports the '612 controllers weren't going to hit mass production until July, so hopefully later this fall we'll start seeing products using the new JMicron controller.)

trim is mostly for ssd's though, and those tend to not have the "goes for a hike" behavior as much......

I wonder if it's worse to batch stuff up, because then the trim itself gets bigger and might take longer.....

Quoted 2 lines

trim is mostly for ssd's though, and those tend to not have the "goes for a hike" behavior as much......

Bench one.

Quoted 2 lines

I wonder if it's worse to batch stuff up, because then the trim itself gets bigger and might take longer.....

They seem to implement a sort of async single threaded trim, which can only have one outstanding trim at a time.

I'm slightly out of my depth here, but: if a single TRIM is issued, which apparently returns quickly, can one then revert to issuing ordinary commands like reads and writes and have them complete as quickly as they normally do, or does any following command have to wait until the trim completes? This could be useful if it turned out we won't stall these devices as long as we don't issue more than one TRIM every few seconds; we could keep a TRIM coalesce queue down to being (say) 5 seconds long (or at least, a configurable small number of seconds).

Quoted 27 lines · Greg Freemyer

Quoted 26 lines · On Thu, Aug 13, 2009 at 12:33 PM, <[email protected]> wrote:

Quoted 10 lines · Markus Trippelsdorf

Quoted 8 lines · Matthew Wilcox

I am planning a complete overhaul of the discard work.  Users can send down discard requests as frequently as they like.  The block layer will cache them, and invalidate them if writes come through.  Periodically, the block layer will send down a TRIM or an UNMAP (depending on the underlying device) and get rid of the blocks that have remained unwanted
in the interim.

Quoted 9 lines

That is a very good idea. I've tested your original TRIM implementation on
my Vertex yesterday and it was awful ;-). The SSD needs hundreds of milliseconds to digest a single TRIM command. And since your implementation
sends a TRIM for each extent of each deleted file, the whole system is unusable after a short while.
An optimal solution would be to consolidate the discard requests, bundle them and send them to the drive as infrequent as possible.

or queue them up and send them when the drive is idle (you would need to keep track to make sure the space isn't re-used)

Quoted 8 lines

Quoted 4 lines

as an example, if you would consider spinning down a drive you don't hurt performance by sending accumulated trim commands.

David Lang

An alternate approach is the block layer maintain its own bitmap of used unused sectors / blocks. Unmap commands from the filesystem just cause the bitmap to be updated.  No other effect.

how does the block layer know what blocks are unused by the filesystem?

or would it be a case of the filesystem generating discard/trim requests to the block layer so that it can maintain it's bitmap, and then the block layer generating the requests to the drive below it?

David Lang

Quoted 44 lines · On Thu, Aug 13, 2009 at 4:44 PM, <[email protected]> wrote:

Quoted 27 lines · Greg Freemyer

Quoted 26 lines · On Thu, Aug 13, 2009 at 12:33 PM, <[email protected]> wrote:

Quoted 10 lines · Markus Trippelsdorf

Quoted 8 lines · Matthew Wilcox

I am planning a complete overhaul of the discard work.  Users can send down discard requests as frequently as they like.  The block layer will cache them, and invalidate them if writes come through.  Periodically, the block layer will send down a TRIM or an UNMAP (depending on the underlying device) and get rid of the blocks that have remained unwanted
in the interim.

Quoted 9 lines

That is a very good idea. I've tested your original TRIM implementation on
my Vertex yesterday and it was awful ;-). The SSD needs hundreds of milliseconds to digest a single TRIM command. And since your implementation
sends a TRIM for each extent of each deleted file, the whole system is unusable after a short while.
An optimal solution would be to consolidate the discard requests, bundle them and send them to the drive as infrequent as possible.

or queue them up and send them when the drive is idle (you would need to keep track to make sure the space isn't re-used)

Quoted 8 lines

Quoted 4 lines

as an example, if you would consider spinning down a drive you don't hurt performance by sending accumulated trim commands.

David Lang

An alternate approach is the block layer maintain its own bitmap of used unused sectors / blocks. Unmap commands from the filesystem just cause the bitmap to be updated.  No other effect.

how does the block layer know what blocks are unused by the filesystem?

or would it be a case of the filesystem generating discard/trim requests to the block layer so that it can maintain it's bitmap, and then the block layer generating the requests to the drive below it?

Quoted 1 line

David Lang

Yes, my thought.was that block layer would consume the discard/trim requests from the filesystem in realtime to maintain the bitmap, then at some later point in time when the system has extra resources it would generate the calls down to the lower layers and eventually the drive.

I highlight the lower layers because mdraid is also going to have to be in the mix if raid5/6 is in use.  ie. At a minimum it will have to adjust the block range to align with the stripe boundaries.

Greg
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Quoted 45 lines · Greg Freemyer

Quoted 44 lines · On Thu, Aug 13, 2009 at 4:44 PM, <[email protected]> wrote:

Quoted 27 lines · Greg Freemyer

Quoted 26 lines · On Thu, Aug 13, 2009 at 12:33 PM, <[email protected]> wrote:

Quoted 10 lines · Markus Trippelsdorf

Quoted 8 lines · Matthew Wilcox

I am planning a complete overhaul of the discard work.  Users can send down discard requests as frequently as they like.  The block layer will cache them, and invalidate them if writes come through.  Periodically, the block layer will send down a TRIM or an UNMAP (depending on the underlying device) and get rid of the blocks that have remained unwanted
in the interim.

Quoted 9 lines

That is a very good idea. I've tested your original TRIM implementation on
my Vertex yesterday and it was awful ;-). The SSD needs hundreds of milliseconds to digest a single TRIM command. And since your implementation
sends a TRIM for each extent of each deleted file, the whole system is unusable after a short while.
An optimal solution would be to consolidate the discard requests, bundle them and send them to the drive as infrequent as possible.

or queue them up and send them when the drive is idle (you would need to keep track to make sure the space isn't re-used)

Quoted 8 lines

Quoted 4 lines

as an example, if you would consider spinning down a drive you don't hurt performance by sending accumulated trim commands.

David Lang

An alternate approach is the block layer maintain its own bitmap of used unused sectors / blocks. Unmap commands from the filesystem just cause the bitmap to be updated.  No other effect.

how does the block layer know what blocks are unused by the filesystem?

or would it be a case of the filesystem generating discard/trim requests to the block layer so that it can maintain it's bitmap, and then the block layer generating the requests to the drive below it?

Quoted 7 lines

Quoted 1 line

David Lang

Yes, my thought.was that block layer would consume the discard/trim requests from the filesystem in realtime to maintain the bitmap, then at some later point in time when the system has extra resources it would generate the calls down to the lower layers and eventually the drive.

Why should the block layer be forced to maintain something that is probably of use for only a limited number of cases? For example, the devices I work on already maintain their own mapping of HOST-visible LBAs to underlying storage, and I suspect that most such devices do. So, you are duplicating something that we already do, and there is no way that I am aware of to synchronise the two.

All we really need, I believe is for the UNMAP requests to come down to us with writes barriered until we respond, and it is a relatively cheap operation, although writes that are already in the cache and uncommitted to disk present some issues if an UNMAP request comes down for recently written blocks.

The unfortunate thing about the TRIM command is that it's not NCQ, so all NCQ commands have to finish, then we can send the TRIM command and wait for it to finish, then we can send NCQ commands again.

So TRIM isn't free, and there's a better way for the drive to find out that the contents of a block no longer matter -- write some new data to it. So if we just swapped a page in, and we're going to swap something else back out again soon, just write it to the same location instead of to a fresh location. You've saved a command, and you've saved the drive some work, plus you've allowed other users to continue accessing the drive in the meantime.

I am planning a complete overhaul of the discard work. Users can send down discard requests as frequently as they like. The block layer will cache them, and invalidate them if writes come through. Periodically, the block layer will send down a TRIM or an UNMAP (depending on the underlying device) and get rid of the blocks that have remained unwanted in the interim.

Thoughts on that are welcome.

Quoted 1 line

Quoted 100 lines · Greg Freemyer

Quoted 61 lines · Richard Sharpe

Quoted 45 lines · Greg Freemyer

Quoted 44 lines · On Thu, Aug 13, 2009 at 4:44 PM, <[email protected]> wrote:

Quoted 27 lines · Greg Freemyer

Quoted 26 lines · On Thu, Aug 13, 2009 at 12:33 PM, <[email protected]> wrote:

Quoted 10 lines · Markus Trippelsdorf

Quoted 8 lines · Matthew Wilcox

I am planning a complete overhaul of the discard work.  Users can send down discard requests as frequently as they like.  The block layer will cache them, and invalidate them if writes come through.  Periodically, the block layer will send down a TRIM or an UNMAP (depending on the underlying device) and get rid of the blocks that have remained unwanted
in the interim.

Quoted 9 lines

That is a very good idea. I've tested your original TRIM implementation on
my Vertex yesterday and it was awful ;-). The SSD needs hundreds of milliseconds to digest a single TRIM command. And since your implementation
sends a TRIM for each extent of each deleted file, the whole system is unusable after a short while.
An optimal solution would be to consolidate the discard requests, bundle them and send them to the drive as infrequent as possible.

or queue them up and send them when the drive is idle (you would need to keep track to make sure the space isn't re-used)

Quoted 8 lines

Quoted 4 lines

as an example, if you would consider spinning down a drive you don't hurt performance by sending accumulated trim commands.

David Lang

An alternate approach is the block layer maintain its own bitmap of used unused sectors / blocks. Unmap commands from the filesystem just cause the bitmap to be updated.  No other effect.

how does the block layer know what blocks are unused by the filesystem?

or would it be a case of the filesystem generating discard/trim requests to the block layer so that it can maintain it's bitmap, and then the block layer generating the requests to the drive below it?

Quoted 7 lines

Quoted 1 line

David Lang

Yes, my thought.was that block layer would consume the discard/trim requests from the filesystem in realtime to maintain the bitmap, then at some later point in time when the system has extra resources it would generate the calls down to the lower layers and eventually the drive.

Why should the block layer be forced to maintain something that is probably of use for only a limited number of cases? For example, the devices I work on already maintain their own mapping of HOST-visible LBAs to underlying storage, and I suspect that most such devices do. So, you are duplicating something that we already do, and there is no way that I am aware of to synchronise the two.

Quoted 6 lines

All we really need, I believe is for the UNMAP requests to come down to us with writes barriered until we respond, and it is a relatively cheap operation, although writes that are already in the cache and uncommitted to disk present some issues if an UNMAP request comes down for recently written blocks.

Richard,

Quoting the original email I saw in this thread:

Quoted 13 lines

The unfortunate thing about the TRIM command is that it's not NCQ, so all NCQ commands have to finish, then we can send the TRIM command and wait for it to finish, then we can send NCQ commands again.

So TRIM isn't free, and there's a better way for the drive to find out that the contents of a block no longer matter -- write some new data to it.  So if we just swapped a page in, and we're going to swap something else back out again soon, just write it to the same location instead of to a fresh location.  You've saved a command, and you've saved the drive some work, plus you've allowed other users to continue accessing the drive in the meantime.

Quoted 9 lines

I am planning a complete overhaul of the discard work.  Users can send down discard requests as frequently as they like.  The block layer will cache them, and invalidate them if writes come through.  Periodically, the block layer will send down a TRIM or an UNMAP (depending on the underlying device) and get rid of the blocks that have remained unwanted in the interim.

Thoughts on that are welcome.

Quoted 1 line

My thought was that a bitmap was a better solution than a cache of discard commands.

Quoted 3 lines

One of the biggest reasons is that a bitmap can coalesce the unused areas into much larger discard ranges than a queue that will only have a limited number of discards to coalesce.

OK, I misunderstood. For the work I did with an SSD company the UNMAP requests were coming down as 1024 LBA DISCARDs/UNMAPs. If someone deleted a multi-GB file that results in thousands of DISCARDS coming down, which is a problem.

However, I wonder if we cannot make do with merging in the block layer, especially with XFS or Ext4.

Quoted 1 line

And both Enterprise scsi and mdraid are desirous of larger discard ranges.

I also would like large discard ranges ... metadata updates in the platform I am thinking of are transactional, and I would like to reduce the number of transactions pushed through the metadata journal.

--
Regards,
Richard Sharpe

Quoted 100 lines · Greg Freemyer

Quoted 61 lines · Richard Sharpe

Quoted 45 lines · Greg Freemyer

Quoted 44 lines · On Thu, Aug 13, 2009 at 4:44 PM, <[email protected]> wrote:

Quoted 27 lines · Greg Freemyer

Quoted 26 lines · On Thu, Aug 13, 2009 at 12:33 PM, <[email protected]> wrote:

Quoted 10 lines · Markus Trippelsdorf

Quoted 8 lines · Matthew Wilcox

I am planning a complete overhaul of the discard work.  Users can send down discard requests as frequently as they like.  The block layer will cache them, and invalidate them if writes come through.  Periodically, the block layer will send down a TRIM or an UNMAP (depending on the underlying device) and get rid of the blocks that have remained unwanted
in the interim.

Quoted 9 lines

That is a very good idea. I've tested your original TRIM implementation on
my Vertex yesterday and it was awful ;-). The SSD needs hundreds of milliseconds to digest a single TRIM command. And since your implementation
sends a TRIM for each extent of each deleted file, the whole system is unusable after a short while.
An optimal solution would be to consolidate the discard requests, bundle them and send them to the drive as infrequent as possible.

or queue them up and send them when the drive is idle (you would need to keep track to make sure the space isn't re-used)

Quoted 8 lines

Quoted 4 lines

as an example, if you would consider spinning down a drive you don't hurt performance by sending accumulated trim commands.

David Lang

An alternate approach is the block layer maintain its own bitmap of used unused sectors / blocks. Unmap commands from the filesystem just cause the bitmap to be updated.  No other effect.

how does the block layer know what blocks are unused by the filesystem?

or would it be a case of the filesystem generating discard/trim requests to the block layer so that it can maintain it's bitmap, and then the block layer generating the requests to the drive below it?

Quoted 7 lines

Quoted 1 line

David Lang

Yes, my thought.was that block layer would consume the discard/trim requests from the filesystem in realtime to maintain the bitmap, then at some later point in time when the system has extra resources it would generate the calls down to the lower layers and eventually the drive.

Why should the block layer be forced to maintain something that is probably of use for only a limited number of cases? For example, the devices I work on already maintain their own mapping of HOST-visible LBAs to underlying storage, and I suspect that most such devices do. So, you are duplicating something that we already do, and there is no way that I am aware of to synchronise the two.

Quoted 6 lines

All we really need, I believe is for the UNMAP requests to come down to us with writes barriered until we respond, and it is a relatively cheap operation, although writes that are already in the cache and uncommitted to disk present some issues if an UNMAP request comes down for recently written blocks.

Richard,

Quoting the original email I saw in this thread:

Quoted 13 lines

The unfortunate thing about the TRIM command is that it's not NCQ, so all NCQ commands have to finish, then we can send the TRIM command and wait for it to finish, then we can send NCQ commands again.

So TRIM isn't free, and there's a better way for the drive to find out that the contents of a block no longer matter -- write some new data to it.  So if we just swapped a page in, and we're going to swap something else back out again soon, just write it to the same location instead of to a fresh location.  You've saved a command, and you've saved the drive some work, plus you've allowed other users to continue accessing the drive in the meantime.

Quoted 9 lines

I am planning a complete overhaul of the discard work.  Users can send down discard requests as frequently as they like.  The block layer will cache them, and invalidate them if writes come through.  Periodically, the block layer will send down a TRIM or an UNMAP (depending on the underlying device) and get rid of the blocks that have remained unwanted in the interim.

Thoughts on that are welcome.

Quoted 1 line

My thought was that a bitmap was a better solution than a cache of discard commands.

Quoted 3 lines

One of the biggest reasons is that a bitmap can coalesce the unused areas into much larger discard ranges than a queue that will only have a limited number of discards to coalesce.

OK, I misunderstood. For the work I did with an SSD company the UNMAP requests were coming down as 1024 LBA DISCARDs/UNMAPs. If someone deleted a multi-GB file that results in thousands of DISCARDS coming down, which is a problem.

However, I wonder if we cannot make do with merging in the block layer, especially with XFS or Ext4.

Quoted 1 line

And both Enterprise scsi and mdraid are desirous of larger discard ranges.

I also would like large discard ranges ... metadata updates in the platform I am thinking of are transactional, and I would like to reduce the number of transactions pushed through the metadata journal.

--
Regards,
Richard Sharpe

Quoted 100 lines · Greg Freemyer

Quoted 61 lines · Richard Sharpe

Quoted 45 lines · Greg Freemyer

Quoted 44 lines · On Thu, Aug 13, 2009 at 4:44 PM, <[email protected]> wrote:

Quoted 27 lines · Greg Freemyer

Quoted 26 lines · On Thu, Aug 13, 2009 at 12:33 PM, <[email protected]> wrote:

Quoted 10 lines · Markus Trippelsdorf

Quoted 8 lines · Matthew Wilcox

I am planning a complete overhaul of the discard work.  Users can send down discard requests as frequently as they like.  The block layer will cache them, and invalidate them if writes come through.  Periodically, the block layer will send down a TRIM or an UNMAP (depending on the underlying device) and get rid of the blocks that have remained unwanted
in the interim.

Quoted 9 lines

That is a very good idea. I've tested your original TRIM implementation on
my Vertex yesterday and it was awful ;-). The SSD needs hundreds of milliseconds to digest a single TRIM command. And since your implementation
sends a TRIM for each extent of each deleted file, the whole system is unusable after a short while.
An optimal solution would be to consolidate the discard requests, bundle them and send them to the drive as infrequent as possible.

or queue them up and send them when the drive is idle (you would need to keep track to make sure the space isn't re-used)

Quoted 8 lines

Quoted 4 lines

as an example, if you would consider spinning down a drive you don't hurt performance by sending accumulated trim commands.

David Lang

An alternate approach is the block layer maintain its own bitmap of used unused sectors / blocks. Unmap commands from the filesystem just cause the bitmap to be updated.  No other effect.

how does the block layer know what blocks are unused by the filesystem?

or would it be a case of the filesystem generating discard/trim requests to the block layer so that it can maintain it's bitmap, and then the block layer generating the requests to the drive below it?

Quoted 7 lines

Quoted 1 line

David Lang

Yes, my thought.was that block layer would consume the discard/trim requests from the filesystem in realtime to maintain the bitmap, then at some later point in time when the system has extra resources it would generate the calls down to the lower layers and eventually the drive.

Why should the block layer be forced to maintain something that is probably of use for only a limited number of cases? For example, the devices I work on already maintain their own mapping of HOST-visible LBAs to underlying storage, and I suspect that most such devices do. So, you are duplicating something that we already do, and there is no way that I am aware of to synchronise the two.

Quoted 6 lines

All we really need, I believe is for the UNMAP requests to come down to us with writes barriered until we respond, and it is a relatively cheap operation, although writes that are already in the cache and uncommitted to disk present some issues if an UNMAP request comes down for recently written blocks.

Richard,

Quoting the original email I saw in this thread:

Quoted 13 lines

The unfortunate thing about the TRIM command is that it's not NCQ, so all NCQ commands have to finish, then we can send the TRIM command and wait for it to finish, then we can send NCQ commands again.

So TRIM isn't free, and there's a better way for the drive to find out that the contents of a block no longer matter -- write some new data to it.  So if we just swapped a page in, and we're going to swap something else back out again soon, just write it to the same location instead of to a fresh location.  You've saved a command, and you've saved the drive some work, plus you've allowed other users to continue accessing the drive in the meantime.

Quoted 9 lines

I am planning a complete overhaul of the discard work.  Users can send down discard requests as frequently as they like.  The block layer will cache them, and invalidate them if writes come through.  Periodically, the block layer will send down a TRIM or an UNMAP (depending on the underlying device) and get rid of the blocks that have remained unwanted in the interim.

Thoughts on that are welcome.

Quoted 1 line

My thought was that a bitmap was a better solution than a cache of discard commands.

Quoted 3 lines

One of the biggest reasons is that a bitmap can coalesce the unused areas into much larger discard ranges than a queue that will only have a limited number of discards to coalesce.

OK, I misunderstood. For the work I did with an SSD company the UNMAP requests were coming down as 1024 LBA DISCARDs/UNMAPs. If someone deleted a multi-GB file that results in thousands of DISCARDS coming down, which is a problem.

However, I wonder if we cannot make do with merging in the block layer, especially with XFS or Ext4.

Quoted 1 line

And both Enterprise scsi and mdraid are desirous of larger discard ranges.

I also would like large discard ranges ... metadata updates in the platform I am thinking of are transactional, and I would like to reduce the number of transactions pushed through the metadata journal.

--
Regards,
Richard Sharpe

Quoted 100 lines · Greg Freemyer

Quoted 61 lines · Richard Sharpe

Quoted 45 lines · Greg Freemyer

Quoted 44 lines · On Thu, Aug 13, 2009 at 4:44 PM, <[email protected]> wrote:

Quoted 27 lines · Greg Freemyer

Quoted 26 lines · On Thu, Aug 13, 2009 at 12:33 PM, <[email protected]> wrote:

Quoted 10 lines · Markus Trippelsdorf

Quoted 8 lines · Matthew Wilcox

I am planning a complete overhaul of the discard work.  Users can send down discard requests as frequently as they like.  The block layer will cache them, and invalidate them if writes come through.  Periodically, the block layer will send down a TRIM or an UNMAP (depending on the underlying device) and get rid of the blocks that have remained unwanted
in the interim.

Quoted 9 lines

That is a very good idea. I've tested your original TRIM implementation on
my Vertex yesterday and it was awful ;-). The SSD needs hundreds of milliseconds to digest a single TRIM command. And since your implementation
sends a TRIM for each extent of each deleted file, the whole system is unusable after a short while.
An optimal solution would be to consolidate the discard requests, bundle them and send them to the drive as infrequent as possible.

or queue them up and send them when the drive is idle (you would need to keep track to make sure the space isn't re-used)

Quoted 8 lines

Quoted 4 lines

as an example, if you would consider spinning down a drive you don't hurt performance by sending accumulated trim commands.

David Lang

An alternate approach is the block layer maintain its own bitmap of used unused sectors / blocks. Unmap commands from the filesystem just cause the bitmap to be updated.  No other effect.

how does the block layer know what blocks are unused by the filesystem?

or would it be a case of the filesystem generating discard/trim requests to the block layer so that it can maintain it's bitmap, and then the block layer generating the requests to the drive below it?

Quoted 7 lines

Quoted 1 line

David Lang

Yes, my thought.was that block layer would consume the discard/trim requests from the filesystem in realtime to maintain the bitmap, then at some later point in time when the system has extra resources it would generate the calls down to the lower layers and eventually the drive.

Why should the block layer be forced to maintain something that is probably of use for only a limited number of cases? For example, the devices I work on already maintain their own mapping of HOST-visible LBAs to underlying storage, and I suspect that most such devices do. So, you are duplicating something that we already do, and there is no way that I am aware of to synchronise the two.

Quoted 6 lines

All we really need, I believe is for the UNMAP requests to come down to us with writes barriered until we respond, and it is a relatively cheap operation, although writes that are already in the cache and uncommitted to disk present some issues if an UNMAP request comes down for recently written blocks.

Richard,

Quoting the original email I saw in this thread:

Quoted 13 lines

The unfortunate thing about the TRIM command is that it's not NCQ, so all NCQ commands have to finish, then we can send the TRIM command and wait for it to finish, then we can send NCQ commands again.

So TRIM isn't free, and there's a better way for the drive to find out that the contents of a block no longer matter -- write some new data to it.  So if we just swapped a page in, and we're going to swap something else back out again soon, just write it to the same location instead of to a fresh location.  You've saved a command, and you've saved the drive some work, plus you've allowed other users to continue accessing the drive in the meantime.

Quoted 9 lines

I am planning a complete overhaul of the discard work.  Users can send down discard requests as frequently as they like.  The block layer will cache them, and invalidate them if writes come through.  Periodically, the block layer will send down a TRIM or an UNMAP (depending on the underlying device) and get rid of the blocks that have remained unwanted in the interim.

Thoughts on that are welcome.

Quoted 1 line

My thought was that a bitmap was a better solution than a cache of discard commands.

Quoted 3 lines

One of the biggest reasons is that a bitmap can coalesce the unused areas into much larger discard ranges than a queue that will only have a limited number of discards to coalesce.

OK, I misunderstood. For the work I did with an SSD company the UNMAP requests were coming down as 1024 LBA DISCARDs/UNMAPs. If someone deleted a multi-GB file that results in thousands of DISCARDS coming down, which is a problem.

However, I wonder if we cannot make do with merging in the block layer, especially with XFS or Ext4.

Quoted 1 line

And both Enterprise scsi and mdraid are desirous of larger discard ranges.

I also would like large discard ranges ... metadata updates in the platform I am thinking of are transactional, and I would like to reduce the number of transactions pushed through the metadata journal.

--
Regards,
Richard Sharpe

It seems to me that unmap is not all that different, why do we need to do it even close in time proximity to the deletes? With a bitmap, we have total timing control of when the unmaps are forwarded down to the device. I like that timing control much better than a cache and coalesce approach.

 > It seems to me that unmap is not all that different, why do we need to > do it even close in time proximity to the deletes?  With a bitmap, we > have total timing control of when the unmaps are forwarded down to the > device.  I like that timing control much better than a cache and > coalesce approach.

The trouble I see with a bitmap is the amount of memory it consumes.  It seems that discards must be tracked on no bigger than 4KB sectors (and possibly even 512 byte sectors).  But even with 4KB, then, say, a 32 TB volume (just 16 * 2TB disks, or even lower end with thin provisioning) requires 1 GB of bitmap memory.  Which is a lot just to store, let alone walk over etc.

So TRIM isn't free, and there's a better way for the drive to find out that the contents of a block no longer matter -- write some new data to it. So if we just swapped a page in, and we're going to swap something else back out again soon, just write it to the same location instead of to a fresh location. You've saved a command, and you've saved the drive some work, plus you've allowed other users to continue accessing the drive in the meantime.

I am planning a complete overhaul of the discard work. Users can send down discard requests as frequently as they like. The block layer will cache them, and invalidate them if writes come through. Periodically, the block layer will send down a TRIM or an UNMAP (depending on the underlying device) and get rid of the blocks that have remained unwanted in the interim.

Quoted 6 lines · Hugh Dickins

But fundamentally, though I can see how this cutdown communication path is useful to compcache, I'd much rather deal with it by the more general discard route if we can. (I'm one of those still puzzled by the way swap is mixed up with block device in compcache: probably because I never found time to pay attention when you explained.)

Quoted 6 lines

You're right to question the utility of the current swap discard placement. That code is almost a year old, written from a position of great ignorance, yet only now do we appear to be on the threshold of having an SSD which really supports TRIM (ah, the Linux ATA TRIM support seems to have gone missing now, but perhaps it's been waiting for a reality to check against too - Willy?).

I am indeed waiting for hardware with TRIM support to appear on my desk before resubmitting the TRIM code. It'd also be nice to be able to get some performance numbers.

Quoted 5 lines

I won't be surprised if we find that we need to move swap discard support much closer to swap_free (though I know from trying before that it's much messier there): in which case, even if we decided to keep your hotline to compcache (to avoid allocating bios etc.), it would be better placed alongside.

It turns out there are a lot of tradeoffs involved with discard, and they're different between TRIM and UNMAP.

Let's start with UNMAP. This SCSI command is used by giant arrays. They want to do Thin Provisioning, so allocate physical storage to virtual LUNs on demand, and want to deallocate it when they get an UNMAP command. They allocate storage in large chunks (hundreds of kilobytes at a time). They only care about discards that enable them to free an entire chunk. The vast majority of users *do not care* about these arrays, because they don't have one, and will never be able to afford one. We should ignore the desires of these vendors when designing our software.

Currently, we have "swap discard" mechanism which sends a discard bio request when we find a free cluster during scan_swap_map(). This callback can come a long time after swap slots are actually freed.

This delay in callback is a great problem when (compressed) RAM [1] is used as a swap device. So, this change adds a callback which is called as soon as a swap slot becomes free. For above mentioned case of swapping over compressed RAM device, this is very useful since we can immediately free memory allocated for this swap page.

This callback does not replace swap discard support. It is called with swap_lock held, so it is meant to trigger action that finishes quickly. However, swap discard is an I/O request and can be used for taking longer actions.

Links:
[1] http://code.google.com/p/compcache/

Signed-off-by Nitin Gupta <[email protected]>

---

 include/linux/swap.h |    5 +++++
 mm/swapfile.c        |   16 ++++++++++++++++
 2 files changed, 21 insertions(+), 0 deletions(-)

include/linux/swap.h +5 -0

index 7c15334..4cbe3c4 100644
@@ -8,6 +8,7 @@
 #include <linux/memcontrol.h>
 #include <linux/sched.h>
 #include <linux/node.h>
+#include <linux/blkdev.h>
 
 #include <asm/atomic.h>
 #include <asm/page.h>

@@ -20,6 +21,8 @@ struct bio;
 #define SWAP_FLAG_PRIO_MASK	0x7fff
 #define SWAP_FLAG_PRIO_SHIFT	0
 
+typedef void (swap_free_notify_fn) (struct block_device *, unsigned long);
+
 static inline int current_is_kswapd(void)
 {
 	return current->flags & PF_KSWAPD;

@@ -155,6 +158,7 @@ struct swap_info_struct {
 	unsigned int max;
 	unsigned int inuse_pages;
 	unsigned int old_block_size;
+	swap_free_notify_fn *swap_free_notify_fn;
 };
 
 struct swap_list_t {

@@ -295,6 +299,7 @@ extern sector_t swapdev_block(int, pgoff_t);
 extern struct swap_info_struct *get_swap_info_struct(unsigned);
 extern int reuse_swap_page(struct page *);
 extern int try_to_free_swap(struct page *);
+extern void set_swap_free_notify(unsigned, swap_free_notify_fn *);
 struct backing_dev_info;
 
 /* linux/mm/thrash.c */

mm/swapfile.c +16 -1

index 8ffdc0d..aa95fc7 100644
@@ -552,6 +552,20 @@ out:
 	return NULL;
 }
 
+/*
+ * Sets callback for event when swap_map[offset] == 0
+ * i.e. page at this swap offset is no longer used.
+ */
+void set_swap_free_notify(unsigned type, swap_free_notify_fn *notify_fn)
+{
+	struct swap_info_struct *sis;
+	sis = get_swap_info_struct(type);
+	BUG_ON(!sis);
+	sis->swap_free_notify_fn = notify_fn;
+	return;
+}
+EXPORT_SYMBOL(set_swap_free_notify);
+
 static int swap_entry_free(struct swap_info_struct *p,
 			   swp_entry_t ent, int cache)
 {

@@ -583,6 +597,8 @@ static int swap_entry_free(struct swap_info_struct *p,
 			swap_list.next = p - swap_info;
 		nr_swap_pages++;
 		p->inuse_pages--;
+		if (p->swap_free_notify_fn)
+			p->swap_free_notify_fn(p->bdev, offset);
 	}
 	if (!swap_count(count))
 		mem_cgroup_uncharge_swap(ent);
--

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Quoted 15 lines · On Wed, 12 Aug 2009 20:07:43 +0530 Nitin Gupta<[email protected]> wrote:

Currently, we have "swap discard" mechanism which sends a discard bio request when we find a free cluster during scan_swap_map(). This callback can come a long time after swap slots are actually freed.

This delay in callback is a great problem when (compressed) RAM [1] is used as a swap device. So, this change adds a callback which is called as soon as a swap slot becomes free. For above mentioned case of swapping over compressed RAM device, this is very useful since we can immediately free memory allocated for this swap page.

This callback does not replace swap discard support. It is called with swap_lock held, so it is meant to trigger action that finishes quickly. However, swap discard is an I/O request and can be used for taking longer actions.

Quoted 3 lines

Links:
[1] http://code.google.com/p/compcache/

Hmm, do you really need notify at *every* swap free ? No batching is necessary ?

Quoted 22 lines · KAMEZAWA Hiroyuki

Quoted 18 lines · On Wed, 12 Aug 2009 20:07:43 +0530 Nitin Gupta<[email protected]> wrote:

Currently, we have "swap discard" mechanism which sends a discard bio request when we find a free cluster during scan_swap_map(). This callback can come a long time after swap slots are actually freed.

This delay in callback is a great problem when (compressed) RAM [1] is used as a swap device. So, this change adds a callback which is called as soon as a swap slot becomes free. For above mentioned case of swapping over compressed RAM device, this is very useful since we can immediately free memory allocated for this swap page.

This callback does not replace swap discard support. It is called with swap_lock held, so it is meant to trigger action that finishes quickly. However, swap discard is an I/O request and can be used for taking longer actions.

Links:
[1] http://code.google.com/p/compcache/

Quoted 3 lines

Hmm, do you really need notify at *every* swap free ? No batching is necessary ?

We need notify for every swap free and no batching is desired, at least for compcache case.

Quoted 15 lines · On Wed, 12 Aug 2009 20:07:43 +0530 Nitin Gupta <[email protected]> wrote:

Currently, we have "swap discard" mechanism which sends a discard bio request when we find a free cluster during scan_swap_map(). This callback can come a long time after swap slots are actually freed.

This delay in callback is a great problem when (compressed) RAM [1] is used as a swap device. So, this change adds a callback which is called as soon as a swap slot becomes free. For above mentioned case of swapping over compressed RAM device, this is very useful since we can immediately free memory allocated for this swap page.

This callback does not replace swap discard support. It is called with swap_lock held, so it is meant to trigger action that finishes quickly. However, swap discard is an I/O request and can be used for taking longer actions.

Quoted 3 lines

Links:
[1] http://code.google.com/p/compcache/

Hmm, do you really need notify at *every* swap free ? No batching is necessary ?

Thanks,
-Kame

Quoted 79 lines

Signed-off-by Nitin Gupta <[email protected]>

---

 include/linux/swap.h |    5 +++++
 mm/swapfile.c        |   16 ++++++++++++++++

 2 files changed, 21 insertions(+), 0 deletions(-)

include/linux/swap.h +5 -0

index 7c15334..4cbe3c4 100644
@@ -8,6 +8,7 @@
  #include <linux/memcontrol.h>
  #include <linux/sched.h>
  #include <linux/node.h>
+#include <linux/blkdev.h>
 
  #include <asm/atomic.h>
  #include <asm/page.h>

@@ -20,6 +21,8 @@ struct bio;
  #define SWAP_FLAG_PRIO_MASK  0x7fff
  #define SWAP_FLAG_PRIO_SHIFT 0
 
+typedef void (swap_free_notify_fn) (struct block_device *, unsigned long);
+
  static inline int current_is_kswapd(void)
  {
       return current->flags & PF_KSWAPD;

@@ -155,6 +158,7 @@ struct swap_info_struct {
       unsigned int max;
       unsigned int inuse_pages;
       unsigned int old_block_size;
+     swap_free_notify_fn *swap_free_notify_fn;
  };
 
  struct swap_list_t {

@@ -295,6 +299,7 @@ extern sector_t swapdev_block(int, pgoff_t);
  extern struct swap_info_struct *get_swap_info_struct(unsigned);
  extern int reuse_swap_page(struct page *);
  extern int try_to_free_swap(struct page *);
+extern void set_swap_free_notify(unsigned, swap_free_notify_fn *);
  struct backing_dev_info;
 
  /* linux/mm/thrash.c */

mm/swapfile.c +16 -1

index 8ffdc0d..aa95fc7 100644
@@ -552,6 +552,20 @@ out:
       return NULL;
  }
 
+/*
+ * Sets callback for event when swap_map[offset] == 0
+ * i.e. page at this swap offset is no longer used.
+ */
+void set_swap_free_notify(unsigned type, swap_free_notify_fn *notify_fn)
+{
+     struct swap_info_struct *sis;
+     sis = get_swap_info_struct(type);
+     BUG_ON(!sis);
+     sis->swap_free_notify_fn = notify_fn;
+     return;
+}
+EXPORT_SYMBOL(set_swap_free_notify);
+
  static int swap_entry_free(struct swap_info_struct *p,
                          swp_entry_t ent, int cache)
  {

@@ -583,6 +597,8 @@ static int swap_entry_free(struct swap_info_struct *p,
                       swap_list.next = p - swap_info;
               nr_swap_pages++;
               p->inuse_pages--;
+             if (p->swap_free_notify_fn)
+                     p->swap_free_notify_fn(p->bdev, offset);
       }
       if (!swap_count(count))
               mem_cgroup_uncharge_swap(ent);
--

Quoted 5 lines

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/