zjuwangg commented on issue #8018:
URL:
https://github.com/apache/incubator-gluten/issues/8018#issuecomment-2496620160
@FelixYBW Thanks for detailed review！
> * We also should consider about the collaboration with RAS.
* RAS sure should be considered!
> * We need to predefine some operators' potential memory usage like Scan or
Project in velox consumes little memory, but aggregate and join need much. So
if a scan + fallback aggregate, we are able to set small offheap + large on
heap. If it's a offloaded agg + fallbacked join, we now needs to set large
offheap + large on heap, in this way we should fallback the agg or even whole
stage then set a large on heap memory.
* Yes, we also have done some very simple work in our inner spark this way
to save resource. Our first draft will not consider detailed operator but just
focus on stage containing fallback operator and huge shuffle status. We could
consider the detailed operator and adjust resource profile more carefully in
the long term.
> * It's even better if we can specify different fallback policy when a task
is retried, which means some task may offload to Velox, some task may retry
with fallback. In theory it's possible but more complex.
We also have considered the situation when task is retied, but current spark
seems no way to change the task's retry resource simpily.
> @PHILO-HE has done some investigation some time ago and noted some code
changes in Vanilla Spark is necessary, did you noted it? if so we may hack the
code in Gluten firstly then submit PR to upstream Spark.
If one stage is totally fallback, there will be no interface to change this
stage resource profile! That's the design FAQ 2 discussed with. Maybe there are
more changes is needed in Vanilla Spark, nice to here more advices.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
