Dynamic LIMIT based on query time
There may be a problem with that design.  As you search for the next batch to delete, you may be skipping over previously checked rows.  So, each subsequent delete will be slower.  The time to finish is (sort of) quadratic.

Two better techniques:


If there are only a "small" number of rows to keep, then build a new table with just them; then swap tables.  Time: linear.  Advantage:  The result is already defragmented.
Walk through the table 1K rows at a time.  Use the PRIMARY KEY for tracking where you are.  And remember where you left off.  Time: linear.


Both of those techniques (and others) are discussed here.