Not well. If serial is a common case, it is important to wrap and drop down to lapack for serial execution.
I implemented this in my code. For 2013 MKL pzhegvx with $n \approx 100 (1000)$ seems to incur 30% (100%) overhead compared to zhegvx when executed in serial.
This seems high to me, so I'm a little worried about my implementation. Note that I ...
For matrices of that size, I'm not sure if you want to use ScaLAPACK at all.
If you've got the ScaLAPACK code already, it shouldn't be hard to implement your own logic to drop into LAPACK instead. At the very least, doing that will allow you to perform the experiments required to answer your own question.
The Scalapack UG link brings up a misleading web page. It looks as if there isn't any Fortran documentation, when I suppose the page is instead intended to be a title page. Clicking on the "Next" button in the upper left-hand corner brings you to the first page of Fortran interface documentation for P_GEMR2D.
There were some hints above already that this may be an integer range problem. A 32 bit signed integer goes up to values of about 2e9. A 50k x 50k symmetric matrix lives in an array of size about 5e4 * 5e4 / 2, which just about fits into an int32. The 100k matrix will no longer be accessed correctly with 32 bit integers.
So you may need to go through your ...
There is source code of this function available here: http://www.netlib.org/lapack/explore-html/dc/de9/group__double_p_osolve.html
As you can see by following the function calls in the code, it computes the Cholesky factorization of $A$ with dpotrf, followed by dpotrs, which solves $AX=B$ by solving two triangular systems (dtrsm).
The implementations of ...